A DOM use case that can't be emulated with direct proxies
bruant.d at gmail.com
Fri Dec 14 00:37:24 PST 2012
Le 14/12/2012 08:25, Brendan Eich a écrit :
> Mark S. Miller wrote:
>> On Thu, Dec 13, 2012 at 7:05 PM, Brendan
>> Eich<brendan at secure.meer.net> wrote:
>>> Boris Zbarsky pointed out on public-script-coord that
>>> window.location and
>>> window.document must be non-configurable _ab initio_, but perhaps
>>> this is
>>> achievable with direct proxies?
>> This resolved into two suggestions, both consistent with ES5 and with
>> direct proxies:
>> * windows.document and window.location must refuse to be configured,
>> but they can still claim to be configurable. ES5 purposely forbids
>> only the opposite mismatch: They can't claim to be non-configurable
>> but still change state in ways that violate that claim.
>> * Allen suggested that these could be non-configurable getter-only
>> accessor properties,
To be more specific, [Unforgeable] properties would be described by
non-configurable getter-only properties.
> window.location can be set by assignment to navigate to a new URL.
location is [Unforgeable, PutForward], so it should be reflected as a
non-configurable getter+setter according to WebIDL.
> Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable
> data property.
oh, web browsers and standards...
There is indeed a pretty violent mismatch between WebIDL and reality, I
guess. Specifically because of the behavior you're describing (assigning
window.location having a behavior), location ought to be an accessor.
What was the rationale that motivated all these browsers to go for data
property? Is it still time to change this behavior?
> In any event, it can't be a getter-only accessor.
>> where the getter stays the same and the magic
>> "switching" behavior is in the getter. (My words for Allen's
>> Either is fine. I like Allen's better.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss