Add a (temporary) global pref to ignore X-Frame-Options

RESOLVED FIXED in mozilla12

Status

()

defect
RESOLVED FIXED
8 years ago
Last year

People

(Reporter: cjones, Assigned: justin.lebar+bug)

Tracking

unspecified
mozilla12
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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.
Assignee: nobody → justin.lebar+bug
Depends on: 704037
Duplicate of this bug: 712974
Summary: Add a global pref to ignore X-Frame-Options → Add a (temporary) global pref to ignore X-Frame-Options
Posted patch Patch v1 (obsolete) — Splinter Review
Attachment #583853 - Flags: review?(bzbarsky)
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...
Posted patch Patch v2Splinter Review
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.)
Attachment #583853 - Attachment is obsolete: true
Attachment #583853 - Flags: review?(bzbarsky)
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.
Attachment #583883 - Flags: review?(bzbarsky)
Comment on attachment 583883 [details] [diff] [review]
Patch v2

r=me
Attachment #583883 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/00f4c8c5bcc7
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Cool, thanks :)
Blocks: 770239

Comment 19

Last year
Looks like it is an issue again. I don't see this setting in the Firefox 59
The pref was temporary, and b2g-specific.  It was presumably removed with the rest of the b2g bits...
You need to log in before you can comment on or make changes to this bug.