Sort out classinfo for modal content windows and chrome windows

RESOLVED FIXED in mozilla9

Status

()

Core
DOM
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla9
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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?
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?
Depends on: 659350
indexedDB should be available everywhere (except in third party windows, but we block that in other ways).
OK, and should it be unconditionally available in modal content windows?  Or conditionally?
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?
Making sure sicking agrees... sicking?
That was my feeling, but it didn't match our existing code, so I just wanted to make sure I wasn't missing anything.
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?
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...
Created attachment 555505 [details] [diff] [review]
Make the set of interfaces exposed by windows saner across different window types.
Attachment #555505 - Flags: review?(jonas)
Priority: -- → P1
Whiteboard: [need review]
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
Attachment #555505 - Flags: review?(jonas) → review?(jst)

Updated

6 years ago
Attachment #555505 - Flags: review?(jst) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/b55b2c3a2fdb
Flags: in-testsuite?
Whiteboard: [need review]
Target Milestone: --- → mozilla9
https://hg.mozilla.org/mozilla-central/rev/b55b2c3a2fdb
Status: NEW → RESOLVED
Last Resolved: 6 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Version: unspecified → Trunk
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?
Er, yes.  Pushed a followup as http://hg.mozilla.org/integration/mozilla-inbound/rev/7ccfcddfed82
https://hg.mozilla.org/mozilla-central/rev/7ccfcddfed82
You need to log in before you can comment on or make changes to this bug.