- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 25 Dec 2013 21:12:27 -0800
- 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