11838 2011-01-23 02:16:56 +0000 In Gecko, Opera, and IE, the "name" property on Window is replaceable 2011-08-04 05:03:01 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#the-window-object P3 normal --- 1 contributor ian ayg bzbarsky cam hsteen ian jackalmage mike mounir pecoraro public-html-admin public-html-wg-issue-tracking w3c w3c public-html-bugzilla oldest_to_newest 44622 0 contributor 2011-01-23 02:16:56 +0000 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 44623 1 bzbarsky 2011-01-23 02:22:57 +0000 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. 44665 2 pecoraro 2011-01-24 16:50:38 +0000 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. 44666 3 pecoraro 2011-01-24 16:53:55 +0000 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! 44668 4 bzbarsky 2011-01-24 17:29:14 +0000 > 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? 44742 5 zcorpan 2011-01-26 10:03:39 +0000 window.name assignments usually survive same-origin navigations and browser restarts. Does this work for non-strings too? 44757 6 w3c 2011-01-26 18:34:28 +0000 Moving non-strings (e.g., objects) across origin boundaries is bad times for security. 45834 7 ian 2011-02-18 22:55:20 +0000 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. 45853 8 bzbarsky 2011-02-19 01:30:39 +0000 > 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. 45854 9 w3c 2011-02-19 01:39:35 +0000 Sounds like it could also cause other patterns for accidental overwrite, such as: var obj = {}; with(obj) { name = "blah"; } 45855 10 w3c 2011-02-19 01:44:05 +0000 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; 45856 11 bzbarsky 2011-02-19 01:56:48 +0000 > 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. 47994 12 ian 2011-05-04 23:26:51 +0000 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. 52605 13 mike 2011-08-04 05:03:01 +0000 mass-moved component to LC1