The problem is:
This relates to the content policy and how iframe works. I added my investigation here:
The proposal, patch, is to let the main toplevel window, be a 'system' priviledge window. But to do this we need to make sure all the inner iframes are not priviledged. The above link shows various tests and so far it's all good. The patch proposal is in a project fork:
I am willing to get a review opinion from Lloyd about this. The patch basically replaces the direct access: file:// with a protocol-based access, which then loads from the file://, but it runs the toplevel with system priviledges. Since this impacts toplevel security the HTML browser page will be able to do things like access to toDataURL(), canvas's drawWindow from any piece of the window, resize to smaller sizes, using DOM.
I think the suggestion is that a recent fix to issue 68 (6d8791d) is a potential solution for this.
If I add "enableSystemPrivileges":true to my app manifest it does make a difference for some sites (e.g. Twitter seems to work).
However, a lot of Google apps behave oddly. For example GMail now gets as far as a loading screen but doesn't get any further. Google Calendar loads but somehow manages to take over the whole screen!
Also, I don't fully understand what adding this parameter to the app manifest means, does it introduce security issues?
gmail does not work but "enableSystemPrivileges":true does make a difference, no idea why.
Regarding why chrome level page works, check this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=593387 i think we need to get input from geckoplatform engineers to help us out here. The bit i heard is that the nature of the iframe docshell is created in a different way. The docshell of the iframe in xul, for example, offers additional attributes. I believe we need to be stronger in making a list of all our browser cases, apps, to show clearly
I wonder if stripping out the "X-Frame-Options" header from the response with nsIObserverService's http-on-examine-response (https://developer.mozilla.org/en/Observer_Notifications#HTTP_requests) for top-level iframes would fix this.
Kinda off-topic: I still have NO idea how Google Calendar can take over the window without any user interaction (though the patch Lloyd landed a couple minutes ago does fix this). Has anyone been able to figure out how they did this?
Probably. We have to annotate again that this is a hack override, so the discussion is alive and see what is the impact of the workaround -- vs security mindset.
I think @davidmurdoch's suggestion looks really promising. I see no real downside. The only hard part is determining what load requests are targeted at top level iframes, but we already solve this problem in other places.
To @taboca's point, sure it's a hack: We're still patching gecko from the outside. But in this case it seems like a robust hack that would fix a problem lots of people care about :)
++ to that too. Just keeping track of things. As soon as this is out I would love to make a video of a functional browser and strongly point out what we doing.
This sounds promising, even if it's really a bit of a hack until a better solution can be found upstream.
Was the patch you're talking about on the master branch? I'd like to try it out with Shell to see if it makes a difference.
@hippygeek yeah, update to master to get the fix that should prevent content from taking over your app in all circumstances (that I can think of)
Whereabouts in the Chromeless source code would you intercept the "X-Frame-Options" header for top level iFrames using the nsIObserverService? And can you point me towards another point in the source code where HTTP requests are identified as being from a top level iFrame?
Aha, I'm guessing the answer to both of my questions may be https://github.com/mozilla/chromeless/blob/master/modules/internal/chromeless-sandbox-window.js
The two main problems I had are:
The nsIHttpChannel interface has a getResponseHeader() and a setResponseHeader() method, but no removeResponseHeader() method so the best I could think to do was (re)set the X-Frame-Options header to null or an empty string, but this doesn't seem to fix the problem.
I'm not sure how you'd detect whether the HTTP response was headed for a top level iFrame because the "subject" of the http-on-examine-response notification is of the interface nsIHttpChannel, not nsIDOMWindow.