19967 2008-07-09 15:01:49 -0700 Variables named "name" become strings 2022-06-03 05:46:40 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) Mac (Intel) OS X 10.5 RESOLVED CONFIGURATION CHANGED http://www.tip.it/runescape/index.php?page=smith_smelt_calc.htm P4 Minor --- 1 tamal zwarich ahmad.saleem792 annevk ap cdumez joepeck jond zwarich oldest_to_newest 85573 0 tamal 2008-07-09 15:01:49 -0700 Run this bit of code in Safari 3.1 or Webkit nightly: javascript:name=names=new Array("foo","bar","bang");alert(typeof(name)+"/"+typeof(names)); or javascript:name=names=function() { return "foo" };alert(typeof(name)+"/"+typeof(names)); It appears that if the variable name is "name", it is automatically typed as a string. In the URL provided, this is causing a problem when using name.length with a for loop. The loop is iterating over every character in the string instead of elements in an array. 85581 1 zwarich 2008-07-09 16:31:06 -0700 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. 222445 2 joepeck 2010-05-07 09:57:21 -0700 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 222804 3 ap 2010-05-07 22:39:33 -0700 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. 222822 4 joepeck 2010-05-07 23:19:37 -0700 (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 222828 5 ap 2010-05-07 23:36:54 -0700 >> 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? 222845 6 joepeck 2010-05-08 00:30:43 -0700 (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 222898 7 joepeck 2010-05-08 10:26:51 -0700 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 222899 8 ap 2010-05-08 10:36:36 -0700 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? 242189 9 ap 2010-06-23 17:49:50 -0700 See also: bug 41003. 246486 10 60491 joepeck 2010-07-04 20:42:27 -0700 Created attachment 60491 [TEST]: Test to Compare Browsers 1872624 11 ahmad.saleem792 2022-05-29 08:44:24 -0700 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! 1872996 12 ap 2022-05-31 09:51:41 -0700 Thank you for checking! Seems like the spec hasn't changed in this regard, so follow-up may be necessary indeed. 1873867 13 annevk 2022-06-03 05:46:40 -0700 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/ 60491 2010-07-04 20:42:27 -0700 2010-07-04 20:42:27 -0700 [TEST]: Test to Compare Browsers test.html text/html 205 joepeck PHNjcmlwdD4KKGZ1bmN0aW9uKCkgewogIHZhciBhcnIgPSBbXTsKICBhcnIucHVzaCggdHlwZW9m IHdpbmRvdy5uYW1lICk7IAogIHdpbmRvdy5uYW1lID0gMTsKICBhcnIucHVzaCggdHlwZW9mIHdp bmRvdy5uYW1lICk7CiAgbmFtZSA9IDE7CiAgYXJyLnB1c2goIHR5cGVvZiB3aW5kb3cubmFtZSAp OwogIGFsZXJ0KCBhcnIgKTsKfSkoKTsKPC9zY3JpcHQ+Cg==