Bug 11960 - Consider making the global scope pollution by names/ids quirks-only
Summary: Consider making the global scope pollution by names/ids quirks-only
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard: CORE-45289
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-02 14:23 UTC by contributor
Modified: 2012-11-27 09:59 UTC (History)
26 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2011-02-02 14:23:28 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#dom-window-nameditem

Comment:
Consider making the global scope pollution by names/ids quirks-only

Posted from: 71.184.125.56
Comment 1 Boris Zbarsky 2011-02-02 14:25:51 UTC
In particular, Gecko does this in quirks mode and we've had very few problems with that (and all the problems we _have_ had were very recent pages written and tested only in Webkit browsers).

The reason to make this a quirk is that this behavior is a significant complication for the web platform that makes writing and debugging scripts much more difficult, because random elements in the DOM can interfere with variable names in your script.  This has bitten every single web page author I know at some point, and the response has always been some variant of "wtf?"
Comment 2 Jonas Sicking 2011-02-02 21:33:00 UTC
It's also a not insignificant performance hit.

I believe I talked with Anne about this at latest TPAC and he thought this was a good idea. I might be misremembering though so cc'ing him to confirm.
Comment 3 Anne 2011-02-03 14:13:15 UTC
Yeah, I am not opposed to making really confusing behavior quirks-only if we can get away with it. (In general I prefer to remove differences between quirks and standards mode, but I have come to accept you cannot apply that rule blindly.)
Comment 4 Boris Zbarsky 2011-02-03 15:15:32 UTC
Yeah, I'm all for reducing the number of quirks, but this behavior is just too screwed up.... ;)
Comment 5 Simon Pieters 2011-02-03 18:47:20 UTC
Anyone know what IE9 does here?
Comment 6 Boris Zbarsky 2011-02-03 21:18:24 UTC
Seems to have the pollution in standards mode too (at least for ids; that's all I tested).
Comment 7 Ian 'Hixie' Hickson 2011-03-04 02:59:31 UTC
I'm willing to change this, but can we get some input from WebKit and Microsoft people first? (Adding quirks isn't something I'd want to do too much.)
Comment 8 Adrian Bateman [MSFT] 2011-03-04 17:37:42 UTC
We made some targeted changes in this area in IE9. Our data suggests that making this quirks only would break a large number of web sites.

Prior to IE9, the "namespace resolvers" for window and document were the same. In IE9 we added support for object elements to parse their fallback content into the DOM. We discovered that it is common on the web for <object> to contain <embed> with the same ID for both and for script to access these with the property. The change we made was that so that the document namespace resolver would only return the element that was "instantiated" with an underlying control (so as not to break Flash injection scripts).
Comment 9 Boris Zbarsky 2011-03-04 18:25:57 UTC
Adrian, are the websites in question running different code in Trident and Gecko?  Or are they all failing in Gecko-based browsers already?
Comment 10 Adrian Bateman [MSFT] 2011-03-04 18:28:17 UTC
I think they usually end up going down different code paths based on other aspects of the page. For example, they are most commonly referring to controls and the object vs. embed differences in different browsers come into play.
Comment 11 Jonas Sicking 2011-03-21 23:44:55 UTC
Adrian: Are these compatibility problems any bigger than ones that already occur due to forked code-paths for IE. I would have imagined that implementing addEventListener for example resulted in some set of sites breaking.

Basically my point is that web and browser devs will be taking pains while these forks exist, with the goals of having them go away and have the same code work in all browsers.

It does seem like polluting the global scope is a pretty big deal and we should really avoid it if at all possible.
Comment 12 Jacob Rossi [MSFT] 2011-03-29 00:23:44 UTC
We certainly wish to raise the bar for what gets added to the global namespace in the future. However, we broke quite a number of top sites when we adjusted how this behaved for just OBJECT/EMBED elements which ultimately resulted in us having to alter our behavior (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12091). Given this experience, we're not in favor of making this a quirk. 

Some of these sites do provide fallback using the document or getElementById, etc. But I'm certain we saw some that didn't (and thus, I would assume were broken in Gecko).

The impact of having names/ids in global scope is minimized by how they have the lowest precedence when JavaScript searches for a given API.  

In case there was any confusion, IE9 follows the current spec text for name/id resolution on the window:

a, applet, area, embed, form, frame, frameset, iframe, img, or object elements that have a name content attribute whose value is name, or
HTML elements that have an id content attribute whose value is name.

http://dev.w3.org/html5/spec/Overview.html#dom-window-nameditem
Comment 13 Boris Zbarsky 2011-03-29 01:12:09 UTC
> The impact of having names/ids in global scope is minimized by how they have
> the lowest precedence when JavaScript searches for a given API.  

As currently specified they have higher precedence than the normal idl-defined stuff, if I read the spec correctly.  Of course not a single browser implements that, and I doubt any ever will.

> But I'm certain we saw some that didn't (and thus, I would assume were
> broken in Gecko).

I would love to see some urls here.  We haven't had anyone report breakage traceable to this issue in a _very_ long time.
Comment 14 Travis Leithead [MSFT] 2011-04-14 19:24:40 UTC
>> As currently specified they have higher precedence than the normal 
>> idl-defined stuff, if I read the spec correctly.  Of course not a 
>> single browser implements that, and I doubt any ever will

Actually, this is only true if the interface has the [OverrideBuiltins] annotation. After implementing this behavior, IE9 had to take the annotation off so that prototype lookups would have higher precedence than the window's "collection" contents. See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10340.

Rather than make a change in user agents that will break some set of sites, why not just encourage the use of ES5 strict mode?
Comment 15 Ian 'Hixie' Hickson 2011-05-10 00:51:28 UTC
Ok. Currently, the spec matches the majority of the browsers. The behaviour is not ideal, nor is having a quirk. There doesn't seem to be a clear consensus on what should happen.

My recommendation would be this: if you want this to change, try to convince the browser vendors to do what you want. If you want this to be as specced, convince the browser vendors that don't match the spec to change to match the spec.

I'll look at this again in a few months (reopen it for me if you remember) to see what the browsers have decided on, and then change the spec to match that. I don't see a better way to go.
Comment 16 Jonas Sicking 2011-05-13 22:43:00 UTC
So we don't have any immediate plans to change this in gecko for now. I.e. we plan to stick with not polluting the global namespace for now.

I'd really like to encourage other browser vendors to go with the behavior that they prefer here so that we can see where compatibility issues arise.
Comment 17 Ian 'Hixie' Hickson 2011-07-15 22:12:06 UTC
sicking: I recommend reaching out to them directly so that they are more motivated to make the change. :-)
Comment 18 Michael[tm] Smith 2011-08-04 05:06:37 UTC
mass-moved component to LC1
Comment 19 Boris Zbarsky 2012-03-22 04:13:19 UTC
Given that some browser vendors are now actively using the global scope polluter in demos the publicise and testcases they create, I'm going to just give up on this.  Who cares about the web, after all.
Comment 20 miket 2012-03-22 12:59:26 UTC
(In reply to comment #19)
> Given that some browser vendors are now actively using the global scope
> polluter in demos the publicise and testcases they create, I'm going to just
> give up on this.  Who cares about the web, after all.

If any of these demos come from Opera, please let me know so I can have them fixed.
Comment 21 Boris Zbarsky 2012-03-22 13:46:57 UTC
They don't come from Opera.
Comment 22 Simon Pieters 2012-03-22 18:43:20 UTC
It seems WebKit currently doesn't pollute the global scope in XHTML.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1416
Comment 23 Simon Pieters 2012-03-26 10:04:14 UTC
Adrian pointed to a site on Twitter that relied on this (before at least): http://slacker.com/

which has the following currently commented-out script:

	        	function getPluginObject(id) {
					var f;
					if (navigator.appName.indexOf("Microsoft") != -1) {
				        f = window[id];
						if (f[0]) {  // in IE9, window['flash_mp3'] returns an array with two elements: the object and the embed
							f = f[0];
						} 
					} else if (navigator.appName.indexOf("Opera") != -1) {
						f	= document.getElementById(id);
				    } else {
				        f = document[id];
				    }
					return f;
				}

It currently uses an almost standards mode doctype. Looking through Web Archive, it seems to have used the same doctype since 2007 (and used no doctype before that).

In our BTS I have come across a URL that relies on this, but that also uses an almost standards mode doctype: http://www.tam.com.br/

I did a search for "window[id]" in dotnetdotcom's web200904, and found only one site that sniffs for "Microsoft" and relies on this in standards mode, but the live site seems to have changed since then: http://ca.ning.com/

it had:

	function getSwf(id) {
		if (navigator.appName.indexOf("Microsoft") != -1) {
				return window[id];
		}
		else {
				return document[id];
		}
	}


What I'm trying to find out here is whether it would be possible to remove the global scope pollution in standards mode but keep it in quirks mode and almost standards mode. So far I have not seen any live URL where this would break.
Comment 24 Simon Pieters 2012-03-26 10:12:59 UTC
(Firefox makes <iframe name=foo></iframe> visible as window.foo in the global scope in standards mode, so I guess we need to keep that in standards mode.)
Comment 25 Boris Zbarsky 2012-03-26 15:09:57 UTC
The common way people use this is not via window[something] but by simply using barewords...  Very hard to grep for.  :(

> So far I have not seen any live URL where this would break.

How about http://ie.microsoft.com/testdrive/performance/irishspring/ ?
Comment 26 Ian 'Hixie' Hickson 2012-08-24 22:37:59 UTC
Back in March, bz WONTFIXed this. Has there been any movement on this? Should I take the note out of the spec? (There's currently a note pointing here saying that we might change this.)
Comment 27 Kyle Huey 2012-08-25 00:04:06 UTC
(In reply to comment #26)
> Back in March, bz WONTFIXed this. Has there been any movement on this? Should I
> take the note out of the spec? (There's currently a note pointing here saying
> that we might change this.)

As of Gecko 14 we now implement the global scope polluter even in standards mode.
Comment 28 Travis Leithead [MSFT] 2012-08-25 00:10:26 UTC
Let's take the note out of the spec then. :0)
Comment 29 Ian 'Hixie' Hickson 2012-08-27 02:06:29 UTC
I don't know if I would smile about taking the note out. I think it's a sad day for the Web (in this case at least in part caused directly by pages on http://ie.microsoft.com/testdrive/ as noted by bz in comment 25).
Comment 30 Boris Zbarsky 2012-11-27 08:34:51 UTC
It's caused by several things, not least of which was that the spec said to do what IE and company did, which made evangelizing sites to not use global scope pollution impossible...  But yes, Microsoft's demos didn't help either.  They weren't as important as all the tested-only-in-WebKit mobile stuff, though.

Ah, well.  Water under the bridge, at this point.
Comment 31 Jonas Sicking 2012-11-27 09:59:20 UTC
This is also a great example of if the spec had said something different we actually would have stood a chance of fixing this right. As things were, evangelism was impossible. Both to authors and to browser implementers.