We should move Window to WebIDL. Then we could do things like have [ChromeOnly] readonly attribute nsIDocShell docshell; and whatnot. Prereqs that probably need separate bugs and can be done somewhat independently of each other: * [Unforgeable] support * [Replaceable] support * Moving support for indexed access on Window to the outer-window proxy object. * [NamedPropertiesObject] support, though this is hard to test without Window being converted. * Adding a [Global] extended attr we can use to make sure to give globals the right sort of jsclass. We would also need to make sure that our bindings only use reserved slot 0, which I think is true. Once the above are done, I think it's a "straightforward" conversion...

Recent es-discuss & public-script-coord discussion led to realize that currently window.location is reflected as a data property. Solving this bug should solve this for Gecko and make location reflected as an own non-configurable accessor. I'm not filing a separate bug, because I don't think it's necessary. I just wanted to keep this in mind.

The spec now requires properties from Window and its superinterfaces to be own properties on the window object. http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0119.html

Comment on attachment 8423108 [details] [diff] [review] v1 >+++ b/dom/bindings/Bindings.conf >- 'register': False, Hmm. So if the pref is flipped without undoing this, we'll have Window.prototype not be window.__proto__, right? The former will be the WebIDL thing, the latter the XPConnect proto. Maybe add comments next to the the pref in all.js to put these 'register': False bits in when flipping the pref? Alternately, we could maybe add a [Pref] on Window in the webidl? Not sure whether that would end up doing the right thing. r=me

(In reply to Boris Zbarsky [:bz] from comment #5) > Hmm. So if the pref is flipped without undoing this, we'll have > Window.prototype not be window.__proto__, right? The former will be the > WebIDL thing, the latter the XPConnect proto. Turns out no, since XPConnect global creation ends up calling PostCreatePrototype which will define the XPConnect proto as window.Window. https://hg.mozilla.org/integration/mozilla-inbound/rev/c744c837c732

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/b06c542b2bf9 for breaking gaia-unit tests: https://tbpl.mozilla.org/php/getParsedLog.php?id=39971272&tree=Mozilla-Inbound

The failures mostly seem to be around EventTarget stuff being detected as "global leaks". I wonder whether the tests are seeing inconsistent views via Xrays and non-Xrays or something....

Although, gaia/source/dev_apps/test-agent/common/vendor/mocha/mocha.js has some nasty hardcoded list of "globals", as does gaia/source/dev_apps/test-ime/lib/mocha.js

The problem is with tests that stub properties on window with the Sinon.JS framework, the stubs are installed as own properties on the object. These properties are then detected as 'leaking' by the Mocha framework. This only happens for properties that are not originally own properties, so basically the EventTarget properties. It's actually a problem with Window on XPConnect too, except that we install the EventTarget WebIDL properties on the XPConnect wrapper (http://hg.mozilla.org/mozilla-central/annotate/cb9f34f73ebe/dom/base/nsDOMClassInfo.cpp#l1809) :-/.

And backed out again. https://hg.mozilla.org/integration/mozilla-inbound/rev/771ac7138d0a Bug 1012944 made |back()| ChromeOnly but didn't fix any tests that depended on it.

Ugh. I'd looked for those, but must have missed them. :( Should we undo the chromeonly bit for "back" for now?

With the fixes for ChromeOnly |back()|. Still waiting for the gaia merge to pick up the fix for bug 1014180.

Comment on attachment 8428576 [details] [diff] [review] v1 Would it not make more sense to use window.history.back() instead of window.back() instead?

Could this have caused a ~10 MiB reduction in the "JS: After TP5" measurements on areweslimyet.com? It certainly looks that way :)

Depending on how many windows are live, possibly: we used to create a bunch of function objects on both the window and its prototype and now they're just on the window itself.