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

Andreas Rossberg rossberg at google.com
Fri Dec 5 03:58:35 PST 2014


On 5 December 2014 at 02:19, Mark Miller <erights at gmail.com> wrote:
> On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky <bzbarsky at 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 at 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


More information about the es-discuss mailing list