Tom S [:evilpie] Reporter
	Description • 11 years ago

We seem to not consistently have the getInterface on the global this. This causes issues with some test262, that compare the result of two consecutive for ... in over the global object. 

Testcase: http://jsfiddle.net/sKYa6/1/ 
For some reason this doesn't always reproduce for me. My own build shows the problem, but the nightly I am using, does not.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 1 • 11 years ago

I say we just add nsIInterfaceRequestor to window classinfo for now...

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 2 • 11 years ago

What causes it to appear sometimes?  The Firefox UI QIing it?  Does that propagate through xrays?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 3 • 11 years ago

> What causes it to appear sometimes?  The Firefox UI QIing it? 

Afaik, yes.

> Does that propagate through xrays?

Again, afaik yes.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 4 • 11 years ago

I'll be glad when that goes away for DOM objects ;-)

	Tom S [:evilpie] Reporter
	Comment 5 • 11 years ago

I assume this is going to be fixed by webidl DOMWindow? Is that going to happen soon?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 6 • 11 years ago

WebIDL window will get us "never", yes, for web content.

But it's not going to happen until a month or more from now at best; no one is actively workin on it.

For this bug, we could just add nsIInterfaceRequestor to the classinfo for window, I guess...

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 11 years ago

This seems to be breaking actual web content (see bug 965790).  I think we should just add this to classinfo for the moment.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 10 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/0f9e691162e6

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 11 • 11 years ago

Comment on attachment 8368214 [details] [diff] [review]
Just always define getInterface on the window for now, so we stop breaking people.  It'll go away once we ship WebIDL window.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Been with us for a while, but has
   recently started breaking sites.
User impact if declined: Some websites (e.g. Udacity) are broken in Firefox.
Testing completed (on m-c, etc.): Passes our tests.
Risk to taking this patch (and alternatives if risky): Risk should be low.  All
   this patch does is make the property always visible to the web page, instead
   of being either visible or not depending on what UI code happens to have run.
String or IDL/UUID changes made by this patch:  None.

	Carsten Book [:Tomcat]
	Comment 12 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/0f9e691162e6

	Ryan VanderMeulen [:RyanVM]
	Comment 13 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/be285c8df31a
https://hg.mozilla.org/releases/mozilla-beta/rev/0450f3309a58

	Kohei Yoshino
	Comment 14 • 11 years ago

Cannot document this if we don't know when it started to happen.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 15 • 11 years ago

I don't think this needs developer documentation.  It "started" to happen probably over a decade ago.

	Kohei Yoshino
	Comment 16 • 11 years ago

Got it.

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

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/0450f3309a58

	Tom S [:evilpie] Reporter
	Comment 18 • 10 years ago

I re-enabled the test262 that this bug or WebIDL window should have fixed: https://hg.mozilla.org/integration/mozilla-inbound/rev/a67d187584ed

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

https://hg.mozilla.org/mozilla-central/rev/a67d187584ed