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?"

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.

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.)

Yeah, I'm all for reducing the number of quirks, but this behavior is just too screwed up.... ;)

Anyone know what IE9 does here?

Seems to have the pollution in standards mode too (at least for ids; that's all I tested).

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.)

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).

Adrian, are the websites in question running different code in Trident and Gecko?  Or are they all failing in Gecko-based browsers already?

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.

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.

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

> 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.

>> 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?

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.

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.

sicking: I recommend reaching out to them directly so that they are more motivated to make the change. :-)

mass-moved component to LC1

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.

(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.

They don't come from Opera.

It seems WebKit currently doesn't pollute the global scope in XHTML.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1416

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.

(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.)

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/ ?

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.)

(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.

Let's take the note out of the spec then. :0)

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).

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.

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.