670235 - Remove nsIDOMWindowInternal

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Patch v1

Reviewer appointed by fair dice roll.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 544894 [details] [diff] [review]
Patch v1

Review of attachment 544894 [details] [diff] [review]:
-----------------------------------------------------------------

Yay!!

Other low hanging fruit: nsIDOMWindowPerformance, nsIDOMStorageIndexedDB, nsIDOMStorageWindow and nsIDOMJSWindow

r=me under the condition that you'll do these in a near future ;-)

Other awesome fruit: nsPIDOMWindow

No "requirement" on this one, but it would be super awesome.

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to comment #1)
> nsIDOMWindowPerformance
> nsIDOMStorageIndexedDB

These still have a pref; once they're supported unconditionally, I'll be happy to.

> nsIDOMStorageWindow

Will do

> nsIDOMJSWindow

This one has name conflicts, open, openDialog and frames in particular.

> nsPIDOMWindow

Once we can express const methods, constructors, and member variables in IDL? :)

Comment 3

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://hg.mozilla.org/mozilla-central/rev/b2ba5a0e5dda

And Neil landed

http://hg.mozilla.org/comm-central/rev/bbf03e583fa4

Comment 4

[Dão Gottwald [:dao]]

need to audit extensions for this

Comment 5

[David :Bienvenu]

and http://hg.mozilla.org/comm-central/rev/93e0048687b7 for Thunderbird

Comment 6

[Steffen Wilberg]

You could rename the parentDOMIntl variables as well:
http://mxr.mozilla.org/mozilla-central/search?string=parentDOMIntl

Comment 7

[Dave Townsend [:mossop]]

Could we re-introduce an empty nsIDOMWindowInternal that just inherits from nsIDOMWindow to avoid breaking so many extensions with this change?

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

This broke many restartless add-ons that were depending on nsIDOMWindowInternal

Comment 9

[Dão Gottwald [:dao]]

(In reply to comment #7)
> Could we re-introduce an empty nsIDOMWindowInternal that just inherits from
> nsIDOMWindow to avoid breaking so many extensions with this change?

I'm pretty sure we can. Do we want to? I would suggest filing a bug on it and requesting tracking-firefox8 to get it sorted out.

Comment 10

[Dave Townsend [:mossop]]

(In reply to comment #9)
> (In reply to comment #7)
> > Could we re-introduce an empty nsIDOMWindowInternal that just inherits from
> > nsIDOMWindow to avoid breaking so many extensions with this change?
> 
> I'm pretty sure we can. Do we want to? I would suggest filing a bug on it
> and requesting tracking-firefox8 to get it sorted out.

Filed bug 675075

Comment 11

[Eric Shepherd [:sheppy]]

Documentation note:

The stuff previously in nsIDOMWindowInternal is now in nsIDOMWindow instead; there is an empty nsIDOMWindowInternal interface so that add-ons that try to use that won't fail; however, they need to be updated to use nsIDOMWindow instead.

Comment 12

[Eric Shepherd [:sheppy]]

Docs have been updated already.