Closed Bug 769771 Opened 8 years ago Closed 8 years ago

add ability to opt-in to content docshell for html:iframes inserted into chrome documents

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla16

People

(Reporter: Gavin, Assigned: Gavin)

References

Details

(Keywords: dev-doc-needed)

Attachments

(1 file)

The social functionality in bug 762569 and the identity sandbox in bug 762993 both want to insert iframes into the hidden window to run script in a hidden sandbox. We want this to run in a type=content docShell, but we can't create a xul:iframe (which supports being marked type="content") because on Win/Linux the hidden window is unprivileged. So we need to make it possible to mark html:iframes as type="content".
Attached patch patch+testSplinter Review
This takes the approach of adding a "mozframetype" attribute, used for non-XUL containers.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #637996 - Flags: review?
Attachment #637996 - Flags: review? → review?(bzbarsky)
Comment on attachment 637996 [details] [diff] [review]
patch+test

r=me
Attachment #637996 - Flags: review?(bzbarsky) → review+
dev-doc-needed: HTML iframes in chrome documents can now specify the mozframetype="content" attribute to opt-in to having a content docShell, which creates a chrome<->content boundary. This is equivalent to the type="content" attribute that already existed on xul:iframes.
Keywords: dev-doc-needed
https://hg.mozilla.org/mozilla-central/rev/8047fce875ac
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Depends on: 772823
Wouldn't it have been safer to make HTML iframes default to type "content", and require the use of mozframetype to make them explicitly privileged?
Yes, that's what the checked-in patch does.  The bug summary just doesn't match what actually happened.  Lemme fix that.  ;)
Summary: add ability to opt-in to content docshell for html:iframes inserted into chrome documents → add ability to opt-in to chrome docshell for html:iframes inserted into chrome documents
Er, I lie.

So yes, it would have been safer.  But it would have broken any existing consumers (e.g. extensions) that are assuming that <html:iframe> is always chrome.  If we'd been willing to break those, we would have just made @type work as the opt-in instead of adding the new attribute....
Summary: add ability to opt-in to chrome docshell for html:iframes inserted into chrome documents → add ability to opt-in to content docshell for html:iframes inserted into chrome documents
dveditz, I fought and lost this battle before too ;).
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.