W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

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

From: Toon Verwaest <verwaest@google.com>
Date: Fri, 05 Dec 2014 12:14:10 +0000
Message-ID: <CANS-YRpFDXf0Ax=Ebrit8F1r+4-8hgvRzjWvgR8oX3rJZ8fp+g@mail.gmail.com>
To: Andreas Rossberg <rossberg@google.com>, Mark Miller <erights@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, es-discuss <es-discuss@mozilla.org>, "Mark S. Miller" <erights@google.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Travis Leithead <travis.leithead@microsoft.com>
This is actually just old code that used to be necessary because of a buggy
implementation of window navigation.

In detail:
V8 uses the split object model with global proxy that has the global object
in its prototype chain; and it reuses the exact global proxy on navigation
for the new page. The global object links back to the global proxy. Previously,
on navigation from GO1 to GO2 the link from the GO1 to the GP was broken
and was linked back to itself. So when GP->GO1 becomes GP->GO2, GO1->GP
became GO1->GO1. Function contexts only store global objects. After
breaking the link, we couldn't get back to the global proxy. When you call
"eval", the receiver during eval is the global proxy. We couldn't find that
global proxy though, so we couldn't set up the context for eval properly;
so we got that exception instead.

I fixed this weirdness about a year ago (to fix related security
issues...). Now GO1->GP stays that way even after navigation. I hadn't come
across this limitation though, so I didn't fix that along with it. I'll
remove it now.

Regards,
Toon

On Fri Dec 05 2014 at 12:59:07 PM Andreas Rossberg <rossberg@google.com>
wrote:

> On 5 December 2014 at 02:19, Mark Miller <erights@gmail.com> wrote:
> > On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >> On 12/4/14, 4:45 PM, Mark Miller wrote:
> >>>
> >>> On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
> >>>>
> >>>> 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?
> >>
> >>
> >> Er, sorry.
> >> http://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-
> old-window-1.html
> >> should work for everyone.
> >>
> >> -Boris
> >
> > Here's an unexpected weirdness, probably not deeply related. Change
> > your first helper page to
> >
> > <script>
> > var someName = "OLD WINDOW";
> > var evil = eval;
> > function f() {
> >   return someName;
> > }
> > function g() {
> >   return (1,evil)("3");
> > }
> > </script>
> >
> > On FF and Safari, I get 3 as expected. On Chrome, I get on my console:
> >
> >     Uncaught EvalError: The "this" value passed to eval must be the
> > global object from which eval originated
> >
> > Especially weird, because this code doesn't pass any this to the
> > renamed eval. I don't know what this means.
>
> This seems to be an attempt to kill off dead window contexts as early
> as possible, in order to avoid memory leaks. Toon might be able to say
> more.
>
> /Andreas
>
Received on Friday, 5 December 2014 18:27:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC