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

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 11:59:33 UTC