This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11838 - In Gecko, Opera, and IE, the "name" property on Window is replaceable
Summary: In Gecko, Opera, and IE, the "name" property on Window is replaceable
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2011-01-23 02:16 UTC by contributor
Modified: 2011-08-04 05:03 UTC (History)
13 users (show)

See Also:


Description contributor 2011-01-23 02:16:56 UTC

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

Posted from:
Comment 1 Boris Zbarsky 2011-01-23 02:22:57 UTC
Testcase is:

    var name = 5;
That alerts "string" and then "string" in Safari/Chrome, and alerts "string" and then "number" in Gecko, Opera, IE8, and IE9 previews.
Comment 2 Joseph Pecoraro 2011-01-24 16:50:38 UTC
I agree, I raised this on the whatwg list 7/2010:

The response by the editor was:

> 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.
Comment 3 Joseph Pecoraro 2011-01-24 16:53:55 UTC
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:
<> Variables named "name" become strings

Still, I would like to see this specced one way or the other!
Comment 4 Boris Zbarsky 2011-01-24 17:29:14 UTC
> 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 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?
Comment 5 Simon Pieters 2011-01-26 10:03:39 UTC assignments usually survive same-origin navigations and browser restarts. Does this work for non-strings too?
Comment 6 Adam Barth 2011-01-26 18:34:28 UTC
Moving non-strings (e.g., objects) across origin boundaries is bad times for security.
Comment 7 Ian 'Hixie' Hickson 2011-02-18 22:55:20 UTC
Given'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 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.
Comment 8 Boris Zbarsky 2011-02-19 01:30:39 UTC
> 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 <>.  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.
Comment 9 Kyle Simpson 2011-02-19 01:39:35 UTC
Sounds like it could also cause other patterns for accidental overwrite, such as:

    var obj = {};
    with(obj) {
       name = "blah";
Comment 10 Kyle Simpson 2011-02-19 01:44:05 UTC
At least in IE, I believe this will also overwrite/replace with a var called `name`:

    try {
    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(){};


    eval("var name = 12;");


    var a = name = 12;
Comment 11 Boris Zbarsky 2011-02-19 01:56:48 UTC
>    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.
Comment 12 Ian 'Hixie' Hickson 2011-05-04 23:26:51 UTC
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:

Status: Rejected
Change Description: no spec change

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.
Comment 13 Michael[tm] Smith 2011-08-04 05:03:01 UTC
mass-moved component to LC1