Boris Zbarsky [:bzbarsky] Reporter
	Description • 12 years ago

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

	David Bruant
	Comment 2 • 12 years ago

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.

	Cameron McCormack (:heycam)
	Comment 3 • 11 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 5 • 10 years ago

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

	Peter Van der Beken [:peterv] Assignee
	Comment 6 • 10 years ago

(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

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 7 • 10 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 8 • 10 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 9 • 10 years ago

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

	Peter Van der Beken [:peterv] Assignee
	Comment 10 • 10 years ago

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

	Peter Van der Beken [:peterv] Assignee
	Comment 11 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/82e3d6f25c5f

	Peter Van der Beken [:peterv] Assignee
	Comment 12 • 10 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 13 • 10 years ago

Ugh.  I'd looked for those, but must have missed them.  :(

Should we undo the chromeonly bit for "back" for now?

	Peter Van der Beken [:peterv] Assignee
	Comment 14 • 10 years ago

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

	Peter Van der Beken [:peterv] Assignee
	Comment 15 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/2587cd80a66e

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 16 • 10 years ago

Comment on attachment 8428576 [details] [diff] [review]
v1

Would it not make more sense to use window.history.back() instead of window.back() instead?

	Ryan VanderMeulen [:RyanVM]
	Comment 17 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/2587cd80a66e

	Nicholas Nethercote [inactive]
	Comment 18 • 10 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 19 • 10 years ago

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.