- From: Bobby Holley <bholley@mozilla.com>
- Date: Thu, 17 Sep 2015 11:57:18 -0700
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Cc: Bobby Holley <bholley@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Adam Klein <adamk@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CAKBxTcKCBp_9QwEQRhbtEb0L94Mk8_GTazOWPGnD1pDguiFGhw@mail.gmail.com>
On Tue, Sep 15, 2015 at 5:18 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote: > > On Sep 15, 2015, at 4:39 PM, Bobby Holley wrote: > > Sorry for the delay here, filter-fail. See > https://bugzilla.mozilla.org/show_bug.cgi?id=1114580#c23 > > Good catch. I've changed the etherpad to: > > - [in-testsuite] [[Get]] - Invoke [[GetOwnProperty]]. If this results in >> a value-prop, return the value. If this results in an accessor prop with a >> getter, invoke the getter. Otherwise, throw. >> > > Let me know if that's insufficient. > > > Note that the ordinary semantics of [[Get]] (and [[Set]] are quite a bit > more complicated than just calling the getter/setter for accessors. See > http://ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-get-p-receiver and > > http://ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver. In > particular, they both have to take their Receiver argument (which is not > necessarily the same as the current object) into account and pass it to the > getter/setter function. Also, note that for [[Set]] the object it is > applied to may be "up the prototype chain" from the Receiver object in > which case a data property write happens to the Receiver object (which > might be in the current domain) and not the target object of the [[Set]]. > (even a crtoss-origin Window or Location object could have been patched > into a prototype chain using [[SetPrototypeOf]]) > Yeah, what I wrote was just intended to be shorthand for all of that, though I agree that we should make sure that whoever write the prose understands this. > Finally, in ES [[Get]] of non-existanct properties normally return > undefined., rather than throwing. > Yes, but plain ES doesn't really have these kinds of security considerations to speak of. We _could_ switch to those kinds of semantics. The advantages would be more consistency with ES and this new special-case we need to add for certain symbols. The downside is that it would change existing browser behavior, decrease defense-in-depth in browser implementations (by requiring us to behave "properly" in more edge cases), and make the source of the difficulties less clear to browser developers. These objects are already super-duper special, so making them behave more consistently with other objects is a non-goal for me - I just want to describe their behavior precisely. bholley > > Allen > > > > > > > Cheers, > bholley > > > On Thu, Jul 16, 2015 at 6:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> On 7/16/15 8:20 PM, Adam Klein wrote: >> >>> But [[Get]] says: >>> >>> Invoke [[GetOwnProperty]]. If there is a getter, invoke it. >>> Otherwise, throw. >>> >> >> Oh. That seems clearly wrong, given that we need to be able to return >> value properties like location.replace. >> >> Bobby, could you fix this, please? We're talking about >> https://etherpad.mozilla.org/html5-cross-origin-objects here. >> >> -Boris >> >> > >
Received on Thursday, 17 September 2015 18:58:10 UTC