For testing the browser app in b2g, we'd like to temporarily disable X-Frame-Options checking. This might be generally useful (maybe), so if we do this, I'd be happy to make it a pref and land on m-c. We won't need this workaround for too long. If anyone strongly objects, or no one else would find it useful, we can close out this bug.
I was going to set this as blocking browser-as-webapp (https://bugzilla.mozilla.org/show_bug.cgi?id=693515) but what's described here is just a workaround. If this is a workaround, what is the long term solution? Should all <iframe browser> elements ignore X-Frame-Options and continue to render the page?
(In reply to Ben Francis from comment #1) > If this is a workaround, what is the long term solution? Should all <iframe > browser> elements ignore X-Frame-Options and continue to render the page? Yes, I think so. Is this really getting in your way at the moment?
No it's not getting in my way at all because I just test the browser on pages without X-Frame-Options, but it will certainly get in users' way. Google, Facebook, Twitter, YouTube, GMail, Google Calendar, Github... most popular web apps disallow rendering inside iFrames in order to prevent phishing. That makes it a blocker as far as a useful browser is concerned.
The question is: Should we hack around it, or fix it properly? We can probably fix it properly, unless it's getting in your way right now and you need a fix.
It sounds like from IRC that cjones thinks this will be In The Way within a week.
<cjones> hi bz, are you ok with a quick hack to disable x-frame-options checking, behind a pref? <cjones> this is to unblock the browser app for b2g, for a quarterly goal <cjones> the downside is ugly, sorry <cjones> upside is we can start testing the browser in real phones sooner * jfkthame (jfkthame@7CAC30AF.5BC345F5.9542EC20.IP) has joined #developers * Mano has quit (Ping timeout) <pr0pagandhi> any plans for an iOS version? * Wes (chatzilla@A1FEE3E8.E3DA2587.9A5171B3.IP) has joined #developers <smaug> ted: ^ * smontagu (chatzilla@moz-13AE8AF9.red.bezeqint.net) has joined #developers * mcote|chiro is now known as mcote <khuey> I think that project died with native UI for android <bz> cjones: worksforme * victorporof (victorporo@3E36101D.6BD22D89.79933D60.IP) has joined #developers <khuey> hmm * victorporof has quit (Connection reset by peer) <bz> cjones: can you make it check system prefs only? <bz> cjones: so users can't set it by accident? Justin might be able to get to this today. If not, please un-assign. When we have bug 704037 or a followup, we will remove this hack.
5 years ago
5 years ago
Comment on attachment 583853 [details] [diff] [review] Patch v1 Won't this possibly still pick up user.js values for this pref?
I thought lockPref() was supposed to prevent that?
I don't know. Does it take effect dynamically?
I added user_pref("b2g.ignoreXFrameOptions", true); to my user.js. Now when I view the pref in about:memory, it has status "locked". Checking what the value is returned by the pref branch...
And with that pref set in user.js and the lockPref() call in place, the pref reads as false. When I take out the lock, it reads as true. Now, it appears that Google has other framebusting code in place, so the page still doesn't load properly with this pref set...
Created attachment 583883 [details] [diff] [review] Patch v2 Move x-frame-options check into CheckFrameOptions, which has the advantage of working. (It worked sometimes as in patch v1, but it works consistently this way.)
Comment on attachment 583883 [details] [diff] [review] Patch v2 I checked that this works on desktop (if I comment out lockPref()) and that when the lock is there, my setting in user_pref is ignored.
Comment on attachment 583883 [details] [diff] [review] Patch v2 r=me
Cool, thanks :)