Last Comment Bug 769771 - add ability to opt-in to content docshell for html:iframes inserted into chrome documents
: add ability to opt-in to content docshell for html:iframes inserted into chro...
Status: RESOLVED FIXED
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: -- normal with 1 vote (vote)
: mozilla16
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
:
Mentors:
Depends on: 772823
Blocks: 762569 762993
  Show dependency treegraph
 
Reported: 2012-06-29 12:48 PDT by :Gavin Sharp [email: gavin@gavinsharp.com]
Modified: 2016-01-04 23:56 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch+test (6.88 KB, patch)
2012-06-29 13:35 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
bzbarsky: review+
Details | Diff | Splinter Review

Description :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-29 12:48:49 PDT
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".
Comment 1 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-29 13:35:23 PDT
Created attachment 637996 [details] [diff] [review]
patch+test

This takes the approach of adding a "mozframetype" attribute, used for non-XUL containers.
Comment 2 Boris Zbarsky [:bz] 2012-06-29 13:40:06 PDT
Comment on attachment 637996 [details] [diff] [review]
patch+test

r=me
Comment 3 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-29 14:05:45 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/8047fce875ac
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-30 06:26:06 PDT
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.
Comment 5 Ryan VanderMeulen [:RyanVM] 2012-06-30 12:43:32 PDT
https://hg.mozilla.org/mozilla-central/rev/8047fce875ac
Comment 6 Daniel Veditz [:dveditz] 2012-10-19 19:28:02 PDT
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?
Comment 7 Boris Zbarsky [:bz] 2012-10-19 19:29:53 PDT
Yes, that's what the checked-in patch does.  The bug summary just doesn't match what actually happened.  Lemme fix that.  ;)
Comment 8 Boris Zbarsky [:bz] 2012-10-19 19:31:34 PDT
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....
Comment 9 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-10-19 21:33:47 PDT
dveditz, I fought and lost this battle before too ;).

Note You need to log in before you can comment on or make changes to this bug.