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

Re: Spec for [Global] does not seem to be quite web-compatible, and none of the UAs are really compatible with each other

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 25 Dec 2013 21:12:27 -0800
Message-ID: <CABZUbM1HYLOc+iz1WjQMzYuJ5APx6Gm9f0xS_EimmbXo9ztHYA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 12/22/13, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/22/13 2:40 AM, Garrett Smith wrote:
>> So if the window.performance API was not `undefined` in, say a browser
>> that supports none of the prior, then the VariableStatement `var
>> performance` would then cause it to be, is that it? And that the
>> initialiser would then potentially get to the bottom of that list and
>> find window.performance, which now points to that var, and not another
>> object.
>
> If the "performance" property is somewhere up the proto chain that's
> what would happen, yes.
>
>>>     var onload;
>>>     (function() {
>>>       onload = { foo: "bar"; };
>>>       doSomething(onload);
>>>     })();
>>>
>>> Some instances of this pattern have a "var onload" inside the function,
>>> but some do not, and it's the latter that are problematic.
>>>
>> Because `onload` now holds the value `undefined`?
>
> No, because the assignment above, if it actually sets the IDL "onload"
> property, sets it to null.
>
Simple assignment to onload = { foo: "bar"; }; should be a
SyntaxError. And it is an early error, so the entire program is
discarded.

If Window.prototype.onload was initially null, and window did not have
an own onload property, then `var onload` either must:
a) Create a variable onload and give it the value `undefined`, as per HTML5
b) Don't.

>> Of those that do not, what do they do?
>
> They end up setting window.onload to null and then passing null to
> doSomething.
>
>> Is there any other way to make Identifier Resolution search first for
>> variables added to the VariableEnvironment.
>
> I'm not trying to make any changes to how ES identifier resolution works
> here.  I think we want to limit the extent of the craziness we have to
> deal with, and hacking identifier resolution for this case is more than
> I'm interested in doing.  ;)
>

If onload exists in the prototype chain, and the VariableEnvironment's
onload is not given the value `undefined`, then what is going on?

How can you avoid craziness when the global object and the global
VariableEnvironment are the same object, and the global object has a
prototype chain? This and the GlobalScopePolluter aren't adequately
specified.

<useless-arcane-knowledge>
The global object as an Object with a prototype chain hearkens to a
problem in BlackBerry9000 browser, which created an Object object for
the ActivationObject (what is now called a Environment Record).
</useless-arcane-knowledge>

The erratum in https://bugs.ecmascript.org/show_bug.cgi?id=78#c0 must
be followed so that var statements at the top level of scripts can
shadow any properties from the global objectís prototype chain.

http://javascript.spec.whatwg.org/#top-level-var-statements
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
Received on Thursday, 26 December 2013 05:12:55 UTC

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