Proposed new API to give additional user-approved privileges to specific web apps which give them increased permissions over the content of iFrames. An example use case is building a web browser as a web app, using iFrames to load web pages in. The current same-origin security model prevents the web app from listening to certain events necessary for using the iFrame as a browser window. See previous similar work done on Mozilla Chromeless https://github.com/mozilla/chromeless/blob/master/modules/lib/web-content.js Example events might include: * Progress monitor - to monitor the progress of the document being loaded inside the iFrame * Load Start - When the iFrame starts loading a new document * Load Stop - When the iFrame finishes loading a new document * Title Change - When the title of the document inside the iFrame changes Other features might include: * Get Title - Get the title of the current HTML document inside the iFrame * Stop Load - Stop the iFrame from loading a document * Suppress XFrame-Options Header - Render the contents of a document inside the iFrame, even if it was returned with an X-Frame-Options DENY or SAMEORIGIN header. (e.g. web sites like GMail which send this header to prevent phishing scams will still be rendered inside this special iFrame). The XUL browser element already has some of these capabilities, but the proposal here is to provide these capabilities to HTML iframe elements.

I vote for this too, mostly from use case from chromeless learnings: * Way to track/observe events, such as page progress, for inner iframes. * Actions such as stop, reload, etc * Way to track/intercept events for history purposes * Way to specify the content security model I think most critical is the relationship from the top level browser and its' one level deep browsers = a browser with tabs case.  In case of chromeless all was an iframe — the top level iframe ( with limited security ) had children = tabs. As Ben Francis pointed ( XFrame-Options ) our case was that some web sites, such as Gmail or AMO [1] were using the HTTP header XFrame-Options and expect browsers to respect. [1] http://hackademix.net/2010/08/31/x-frame-options-finally-on-vanilla-firefox/ However it's worth noticing that Firefox code runs the iframe in a different way [2] when the iframe is in the system privileged context. This is what made possible for AMO to run in an iframe when you use the Tools -> Addons menu in Firefox. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=593387 So even in Chromeless, we were able to create a case with the top level "app" iframe-based browser with system-level privileges so it's primary ( one level deep iframes = tabs ) worked okay. My understanding was that iframe is instantiated in different ways depending on the nature of the top level window. The dilema in chromeless was exactly there. Option a) Run the top browser like XUL and then try to limit the inners, or b) run the top like a browser content ( super safe ) and create a bunch of JS-based means ( message-based safe etc ) to access special API and that is why some ideas of "hacking" the header was brought to the table. It seemed odd for me, but I respected that hacking headers was a cheap way to make the case. Unfortunately I had no deep level of understanding on how iframe browsers were created to see if we could access CSP as API or fix in other ways.

This bug is partly a duplicate of this other bug https://bugzilla.mozilla.org/show_bug.cgi?id=693515 Marcio, you might want to add your comments there.