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".

This takes the approach of adding a "mozframetype" attribute, used for non-XUL containers.

Comment on attachment 637996 [details] [diff] [review] patch+test r=me

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.

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. ;)

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....

dveditz, I fought and lost this battle before too ;).