680903 - Sort out classinfo for modal content windows and chrome windows

Status: RESOLVED FIXED

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

Description

[Boris Zbarsky [:bzbarsky]]

See bug 659350 comment 31.  Modal content windows and chrome windows are missing some interfaces that normal content windows have.

Jonas, Ben: should chrome windows support indexeddb in classinfo?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Er, looks like in fact chrome and modal content windows _do_ support indexeddb.  Unconditionally, unlike content windows.

Doug, you made that change in bug 623316.  Why is the support for modal content windows unconditional?

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

indexedDB should be available everywhere (except in third party windows, but we block that in other ways).

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK, and should it be unconditionally available in modal content windows?  Or conditionally?

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I don't see any reason why modal content windows should be any different from regular content windows... Is there something that sets them apart that I'm missing?

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Making sure sicking agrees... sicking?

Comment 6

[Boris Zbarsky [:bzbarsky]]

That was my feeling, but it didn't match our existing code, so I just wanted to make sure I wasn't missing anything.

Comment 7

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

I'm also not sure why modal makes a difference.

I could however see that being able to open a new "toplevel" window from deeply within a frame hierarchy could be used as a way to circumvent the 3rd party checks that we have.

We've been kind'a relying on the popup blocker and the fact that sites don't want to open popups in order to have them not work around our 3rd party block. Is the concern that modal windows somehow changes this?

Comment 8

[Boris Zbarsky [:bzbarsky]]

To be clear, right now modal content windows unconditionally allow indexeddb.  I was assuming that's for some reason, but it starting to sound like it was just a bug...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Make the set of interfaces exposed by windows saner across different window types.

Comment 10

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

Comment on attachment 555505 [details] [diff] [review]
Make the set of interfaces exposed by windows saner across different window types.

I think jst, peterv or mrbkap would make better reviewers here

Comment 11

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b55b2c3a2fdb

Comment 12

[Ed Morley [:emorley]]

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

Comment 13

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

Comment on attachment 555505 [details] [diff] [review]
Make the set of interfaces exposed by windows saner across different window types.

>--- a/dom/base/nsDOMClassInfo.cpp
>+++ b/dom/base/nsDOMClassInfo.cpp
>   // FIXME: Bug 680903.  Should ModalContentWindow really not have
>   // touch, performance apis and have unconditional indexeddb??

Fixed?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Er, yes.  Pushed a followup as http://hg.mozilla.org/integration/mozilla-inbound/rev/7ccfcddfed82

Comment 15

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/7ccfcddfed82