X-Frame-Options - Pages with X-Frame-Options are not rendered in the imediate iframe due about chromeless

[davidmurdoch]

I don't think the JavaScript version of mail.google.com will load even though a patch landed for this. I'm not sure why.

[benfrancis]

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?

[viktorkelemen]

thanks @hippygeek
gmail does not work but "enableSystemPrivileges":true does make a difference, no idea why.

[taboca]

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

[davidmurdoch]

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?

[taboca]

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.

[lloyd]

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 :)

[taboca]

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

[benfrancis]

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.

Thanks

[lloyd]

@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)

[benfrancis]

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?

[benfrancis]

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

[benfrancis]

Well, I had a stab at this (https://github.com/hippygeek/chromeless/commit/8937cafa1fafb040fb3a0281aa3c9bc3b6fd0433) but I didn't get very far. I'm hoping it's just that my JavaScript foo isn't strong enough and that someone can help.

The two main problems I had are:

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