Named property interceptor interfering with accessor properties on the same object
Domenic Denicola
[re-sending with correct v8-users address this time]
Sorry, I must not have explained correctly. I know that per Web IDL named properties are data properties. I am having trouble however figuring out how the V8 API will allow an object to have both a named property interceptor, and accessors, on the same object. When I add a named property interceptor to the object, it changes the object so that even when I define accessors on it, it now always reflects them as data properties.
My example, of window.frames, was meant to show this. Chrome reflects it as a data property, not an accessory property. Additionally, it is not a named property, so I should be able to redefine it. Currently in Chrome you cannot redefine it, probably because of the same named property interceptor issue.
I was wondering what you planned to do to address this in Chrome, on a technical level, so that I could investigate similar fixes in Node.js.
From: yukis...@google.com [mailto:yukis...@google.com]
On Behalf Of Yuki Shiino
Sent: Tuesday, September 8, 2015 03:02
To: Domenic Denicola <d...@domenic.me>
Cc: blink-dev <blin...@chromium.org>; Yuki Shiino <yukis...@chromium.org>
Subject: Re: [blink-dev] Re: Binding team snippet
First of all, "named properties" are not DOM attributes. They're special and different from attributes.
Attributes are defined as accessor-type properties by the spec, while named properties are defined as data-type properties by the spec. So it's expected that named properties are data-type properties.
You cannot do [[DefineOwnProperty]] for named properties. Exactly speaking, you can do, but it gets rejected.
The problems you're facing seem no problem, they're the correct behaviors in terms of the Web IDL spec.
Cheers,
Yuki Shiino
2015-09-08 15:41 GMT+09:00 Domenic Denicola <d...@domenic.me>:
On Tuesday, September 8, 2015 at 2:37:12 AM UTC-4, Kentaro Hara wrote:Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet.
That is exactly the goal of all the work yukishiino@ has been doing :) We still need a substantial amount of work to get Window's members right but are planning to fix it by the end of Q4. See yukishiino@'s slide (https://docs.google.com/presentation/d/18Ap_EKEBu7nzDrlFM7FbCR4EgrNd3ryLabJUh-YvEwM/edit#slide=id.g2480feb0_1_0) for more context.
Right, thanks! yukishiino@, do you have any thoughts in particular about the issue with V8's named property interceptor APIs only allowing data descriptors? Do you plan to change V8, or is there a different solution that I am missing?
On Tue, Sep 8, 2015 at 3:29 PM, Domenic Denicola <d...@domenic.me> wrote:
Has there been any effort yet to move the window attributes to be getters instead of data properties? I remember hearing this was planned but wasn't sure if you'd started yet.
The reason I ask is that I am actually running in to very similar problems with Node.js. We have created "window like" objects using V8's SetNamedPropertyHandler and are noticing that all the accessor properties we define on this global object are now being exposed as data properties when you do `Object.getOwnPropertyDescriptor(globalProxy, "prop")`. `Object.defineProperty` does not work well on them either, just like in Chrome: Object.defineProperty(window, "frames", { get() { return 5; } }) will not change the result of Object.getOwnProperty(window, "frames"). So I was wondering if you'd started investigating fixes to this.
Happy to take this offline or to v8-users if you think that would be more appropriate.
On Sunday, September 6, 2015 at 8:35:26 PM UTC-4, Kentaro Hara wrote:Hi
(yukishiino) Made the default receiver of callback functions "undefined". See this CL for more details: https://codereview.chromium.org/1301423004/.
(yukishiino) Trying to move Window's methods from a prototype chain to an instance object (Note: Methods in [Global] objects need to be defined on an instance object, not a prototype chain). However, yukishiino@ hit a complex issue around Window.toString(). We decided to skip Window.toString() at the moment.
--
Kentaro Hara, Tokyo, Japan
--
Kentaro Hara, Tokyo, Japan
Yuki Shiino
I'm sorry that I misunderstood your question. Maybe I'm still misunderstanding... Please correct me if any.There are (at least) two modes in the named property interceptor, masking and non-masking. When masking mode, named properties have priority over other regular members (attributes, etc.), so your named property handler is invoked for every name look-up regardless of whether it's named property or regular member.When non-masking mode (Web IDL spec requires the non-masking mode), regular members have priority over named properties. The named property handler is invoked only when the name does not match with any member of the object or any member on the prototype chain. The named property handler is invoked only when nothing is found.You can set v8::PropertyHandlerFlags::kNonMasking flag into v8::NamedPropertyHandlerConfiguration when you install the named property handler. We recently switched to this non-masking mode.For another question why "window" object in Blink returns data-type properties for attributes, that's a separate issue. That has nothing to do with the named properties. We have several issues internally and we cannot make Window's attributes accessor-type properties at the moment. But we're actively working to fix the issues, and we'll make Window's attributes accessor-type properties (hopefully in this year).Cheers,Yuki Shiino