It seems that either the getter or the setter for the window.name property is converting the value to a string. This is an interesting bug, but it shouldn't be too hard to fix.

I think this is expected behavior. window.name is an actual property to set the (string) name of the browsing context:
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#apis-for-creating-and-navigating-browsing-contexts-by-name

Compare to:

javascript:window.name=new Array("foo","bar","bang");alert(typeof(window.name));

In Firefox, this says "string", but the original test case says "object". So, this is more about what "name" refers to in different contexts, not about window.name behavior.

(In reply to comment #3)
> So, this is more about what "name" refers to in different contexts,
> not about window.name behavior.

I disagree. The three cases seen here all show window.name is type string, and that the same value in a different variable shows a different type. I believe this was the original way that the author was trying to show that typeof window.name is always string.

> javascript:name=names=new Array("foo","bar","bang");alert(typeof(name)+"/"+typeof(names));

  typeof name => "string"
  typeof names => "object"

> javascript:name=names=function() { return "foo" };alert(typeof(name)+"/"+typeof(names));

  typeof name => "string"
  typeof names => "function"

Your example is just a simplification of the first.


> In Firefox, this says "string", but the original test case says "object".

It was `names`, not `name` that was object =)


I think you are on the right track about contexts, but that just leads me back to the `window.name` special case. Any time you use the variable with name `name` in the global scope it will be `window.name` and have the special properties. However, if you make a new scope (which I believe can only be down with functions in JavaScript) you get expected results:

> javascript:(function() { var name = 1;  alert(typeof name); })()

  typeof name => "number"

The special case of `window.name` can be recreated in JavaScript using a getter on the global variable. Lets do the same thing with a property named `goose`. A much jollier and less confusing variable name ;)

  (function() {
    var private = ""; // Keep the real data private
    window.__defineGetter__('goose', function() {
      return private;
    });
    window.__defineSetter__('goose', function(x) {
      private = String(x);
      return x; // Preserve chain behavior
    });
  })()

Now usage appears the same as `window.name`

  var goose = [1,2,3];
  typeof goose;         // "string"
  goose;                // "1,2,3"
  
  var name = [1,2,3];
  typeof name;          // "string"
  name;                 // "1,2,3"

Its worth noting that using var multiple times is not a syntax error, and does nothing if the variable is already in initialized.

  var x = 10;
  var x = 5; // harmless, but frowned upon

>> In Firefox, this says "string", but the original test case says "object".
> It was `names`, not `name` that was object =)

In fact, both are objects. For the first case in bug description, Firefox 3.5 says object/object.

Are you running each test in a new window or tab?

(In reply to comment #5)
> >> In Firefox, this says "string", but the original test case says "object".
> > It was `names`, not `name` that was object =)
> 
> In fact, both are objects. For the first case in bug description, Firefox 3.5
> says object/object.

This is very fascinating to me. Thanks for pointing it out.

It looks like Firefox special cases a number of the properties on Window. A glance at their IDL files shows a comment that these variables are "replaceable". So you end up with the following behavior:

  window.name;            // ""
  window.name = 1;        // (the result is 1, expected chainable assignment)
  window.name;            // "1"
  window.name = [1,2,3];  // (same thing, chainable)
  window.name;            // "1,2,3"
  
  // First time the user accesses the global "name" things go wild!
  name = 1;
  window.name;            // 1 (what!?!?!)
  window.name = [1,2,3];
  window.name;            // [1,2,3]

My guess is that Firefox was trying to save developers from the weirdness that is window.name. I don't really know which behavior I would recommend. So here is a test case:

  (function() {
    var arr = [];
    arr.push( typeof window.name ); 
    window.name = 1;
    arr.push( typeof window.name );
    name = 1;
    arr.push( typeof window.name );
    alert( arr );
  })();

Produces the following values in the browsers I have on my system:

  Safari 4.0.5 / WebKit Nightly and Chrome 5
  "string,string,string"

  Firefox 3.6.3 and Opera 10.5.3
  "string,string,number"

My interpretation of the HTML5 spec sides with Safari / Chrome. However, that doesn't mean its right. I did a quick search through the WHATWG archives and didn't see any discussion on the lists. There was something interested, and I would say "related" but not the same on public-html:
http://lists.w3.org/Archives/Public/public-html/2009Nov/0302.html

I dug a bit more. That public-html link pointed to an HTML5 bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241

It describes new WebIDL properties [ReplaceableNamedProperties] and [Replaceable]. Only the latter seems to be defined in WebIDL, and it matches the weirdness I saw above:
http://dev.w3.org/2006/webapi/WebIDL/#Replaceable

However, the HTML5 spec doesn't make window.name replaceable. Just a bunch of other properties!
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object

WebKit also has the notion of replaceable properties, see e.g. DOMWindow.idl.

It would seem that adding [Replaceable] to the name attribute in our IDL could solve this, but I actually suspect that this has been discussed and investigated before, and could have been an intentional choice. Maybe you could try this change, and see which tests break?

See also: bug 41003.

Created attachment 60491 [details]
[TEST]: Test to Compare Browsers

Outputs from all browsers:

Safari 15.5 on macOS 12.4 - string,string,string
Firefox Nightly 102 - string,string,string
Chrome Canary 104 - string,string,string

Since all browsers are consistent and have same output to attached test case. I think this bug should be closed and if there is spec issue then it should be raised separately. Thanks!

Thank you for checking! Seems like the spec hasn't changed in this regard, so follow-up may be necessary indeed.

The specification always reflected WebKit here I think. So Firefox must have changed at some point to no longer have this property as `[Replaceable]`. All seems good. \o/