This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html Section: http://www.whatwg.org/specs/web-apps/current-work/#the-window-object Comment: In Gecko and Opera, at least, the "name" property on Window is replaceable. Should that be specced, or is it web-compatible enough to not make it replaceable? Posted from: 71.184.125.56
Testcase is: <script> alert(typeof(name)); </script> <script> var name = 5; alert(typeof(name)); </script> That alerts "string" and then "string" in Safari/Chrome, and alerts "string" and then "number" in Gecko, Opera, IE8, and IE9 previews.
I agree, I raised this on the whatwg list 7/2010: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027002.html The response by the editor was: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027831.html > I am told IE says "string,string,string" (thanks to Tab and Aryeh). > > This argues that we should not make it replaceable unless it breaks pages.
Given Boris's comment that IE8 and IE9 make this replaceable, then maybe it is just WebKit that is an outlier now. The WebKit bug on this is: <http://webkit.org/b/19967> Variables named "name" become strings Still, I would like to see this specced one way or the other!
> I am told IE says "string,string,string" (thanks to Tab and Aryeh). ccing them. It looks like in IE the presence or absence of |var| there is key. If it's present, then a new property is presumably created on the global object which shadows the property on the prototype, which is why you end up with "number" alerted for the second alert in my testcase. If I change the testcase in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027002.html to say "var name = 1" and not use a function wrapper around the code, then IE alerts "undefined,number,number", Gecko alerts "string,string,number", Safari and Chrome alert "string,string,string", Opera alerts "undefined,number,number". So maybe the |name| property doesn't need to be replaceable if it actually lives on the prototype instead of the window itself and if |var| introduces a new property of that name on the window itself?
window.name assignments usually survive same-origin navigations and browser restarts. Does this work for non-strings too?
Moving non-strings (e.g., objects) across origin boundaries is bad times for security.
Given window.name's rather complicated magic, if we _can_ make it non-replaceable, we should, IMHO. Is there evidence that this needs to be replaceable for compat? The difference in behaviour with 'var' vs no-'var' seems unsupported by the JS spec; am I misreading the spec? I really have no idea what I should be speccing here if window.name is to be replaceable and if WebIDL and the JS spec don't make the stuff about the prototype that bz describes in comment 4 automatically work. If that is indeed what should happen, some advice as to how to spec it would be very welcome.
> The difference in behaviour with 'var' vs no-'var' seems unsupported by the JS > spec; am I misreading the spec? I believe 'var' vs no-'var' should in fact behave differently. See <https://bugzilla.mozilla.org/show_bug.cgi?id=632003#c1>. Whether that erratum has made it to the official drafts, I don't know. So it sounds like we could just make 'name' live on Window.prototype and be a regular getter/setter pair there. It would mean that doing |name = "foo"| at global scope without declaring |var name| beforehand would actually rename the window, which seems somewhat undesirable for authors. But maybe that's ok.
Sounds like it could also cause other patterns for accidental overwrite, such as: var obj = {}; with(obj) { name = "blah"; }
At least in IE, I believe this will also overwrite/replace window.name with a var called `name`: try { nonexistent(); } catch (name) { } As in IE, the variable in the catch-clause gets created as a variable in the containing scope. Also, what about: function name() {} And (again, in IE, bug with NFE's): var a = function name(){}; And: eval("var name = 12;"); And: var a = name = 12;
> eval("var name = 12;"); This would just add a prop on the window, I think. I'd have to double-check. > var a = name = 12; This is the same as |name = 12|, sure.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If I understand the above correctly, the conclusion here is that |name| doesn't have to be replaceable, and thus this should be WONTFIX. I'm not 100% sure I understood all the subtleties above, though, so if I'm wrong please reopen the bug.
mass-moved component to LC1