Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/4/14, 1:36 PM, Travis Leithead wrote:
>>>
>>> Note that "window" is not the global.  It's a proxy whose target is the
>>> global.
>>
>>
>> Yes, but within a browser UA, there is no way to get a reference to the
>> naked global because all entry-points return window proxies ;-)
>
>
> Well, no way from web script.  The browser internals can do it, presumably,
> right?
>
>>> Well, good question.  If we don't do this restriction (by which I assume
>>> defineProperty throwing; I assume getOwnPropertyDescriptor claiming
>>> configurable always is less controversial), what do we want to do?
>>
>>
>> As I look back on your original message, I fail to see what the problem
>> is. You seem to think that the window proxy is referring to the same window
>> object before and after the navigation.
>
>
> The window proxy object identity does not change before and after the
> navigation.
>
> The window object the proxy is pointing to changes.
>
>> In fact, in most implementations that I'm aware of, there is the concept
>> of the "inner" and "outer" window.
>
>
> Yes, I'm well aware.
>
>> The "outer" window is the window proxy, which is the object that
>> implements the cross-origin access control.
>
>
> In Gecko, the cross-origin access control is actually implemented using a
> separate security membrane proxy whose target is the "outer" window. But
> sure.
>
>> In IE's implementation, the window proxy has no storage as a typical JS
>> var--it's only a semi-intelligent forwarder to its companion "inner" window.
>
>
> That's an IE implementation detail.  In Gecko, the "window proxy" is a JS
> proxy object with a proxy handler written in C++.  That, too, is an
> implementation detail.
>
> What matters here is what JS consumers see.  Consumers typically (there are
> some exceptions involving scope chains) just see the window proxy, yes?
>
> So when a script does:
>
>   Object.defineProperty(frames[0], "foo", { value: true; });
>
> It is defining a property on frames[0].  The fact that this is actually a
> proxy for some other object (the global inside that iframe) is somewhat of
> an implementation detail, again.  From the consumer's and the spec's point
> of view, frames[0] is something with some internal methods
> ([[GetOwnProperty]], [[DefineOwnProperty]], etc) which are implemented in
> some way.  Still from the spec's point of view, the implementation of these
> internal methods must satisfy
> <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-invariants-of-the-essential-internal-methods>.
>
>> So, in your code sample, your "defineProperty" call forwarded to the
>> "inner" window where the property was defined.
>
>
> Sure.  I understand that.  As in, the proxy's [[DefineOwnProperty]] invoke's
> the target's [[DefineOwnProperty]].
>
>> After the navigation, the "inner" window was swapped out for a new one
>> (and whole new type system at that) which the existing window proxy ("outer"
>> window) now refers.
>
>
> Sure.
>
>> This gave the appearance of the non-configurable property disappearing
>
>
> This isn't about "appearance".  The relevant spec invariant for
> [[GetOwnProperty]], for example, is:
>
>   If P’s attributes other than [[Writable]] may change over time or
>   if the property might disappear, then P’s [[Configurable]] attribute
>   must be true.
>
> And Object.getOwnPropertyDescriptor is clearly defined to invoke
> [[GetOwnProperty]].
>
> So when a page does Object.getOwnPropertyDescriptor(window, "foo") this is
> invoking the window proxy's [[GetOwnProperty]].  That's allowed to do all
> sorts of stuff as long as it preserves the invariants involved, including
> the one I quote above.  The fact that the "disappearing" is due to the
> target changing is an implementation detail of the window proxy.
>
>> but in reality it would still be there if you could get a reference to the
>> "inner" window
>
>
> Which doesn't matter, because the consumer is not interacting with the
> "inner" window.
>
>> *I wonder if you can capture the inner window in a scope chain or closure
>> somehow
>
>
> Sure, for a scope chain.  Testcase at
> https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html

That page demands a client certificate. Is that intentional?


> shows "OLD WINDOW" on the first line in Firefox, Chrome, and Safari.  In
> IE11 it throws a "Can't execute code from a freed script" exception; I can't
> find anything in the specs that allows that, fwiw.
>
>> so that you could observe that "foo" is still there even though you can't
>> directly see it anymore?
>
>
> Absolutely.
>
>> I think that might work if the executing code was defined in the old
>> iframe's environment and executed after navigation...
>
>
> Right.
>
> But we're not talking about indirect probes like this here, just about the
> basic invariants object internal methods are supposed to preserve.
>
>
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
  Cheers,
  --MarkM

Received on Friday, 5 December 2014 00:45:53 UTC