The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla16

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: Gavin, Assigned: Gavin)

Tracking

({dev-doc-needed})

unspecified
mozilla16
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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".
Created attachment 637996 [details] [diff] [review]
patch+test

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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8047fce875ac
Target Milestone: --- → mozilla16
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
Last Resolved: 5 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 ;).
You need to log in before you can comment on or make changes to this bug.