Closed
Bug 707893
Opened 13 years ago
Closed 13 years ago
Add a (temporary) global pref to ignore X-Frame-Options
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: cjones, Assigned: justin.lebar+bug)
References
Details
Attachments
(1 file, 1 obsolete file)
3.65 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•13 years ago
|
||
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?
Assignee | ||
Comment 2•13 years ago
|
||
(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?
Comment 3•13 years ago
|
||
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.
Assignee | ||
Comment 4•13 years ago
|
||
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.
Assignee | ||
Comment 5•13 years ago
|
||
It sounds like from IRC that cjones thinks this will be In The Way within a week.
Reporter | ||
Comment 6•13 years ago
|
||
<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
Reporter | ||
Updated•13 years ago
|
Summary: Add a global pref to ignore X-Frame-Options → Add a (temporary) global pref to ignore X-Frame-Options
Assignee | ||
Comment 8•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Attachment #583853 -
Flags: review?(bzbarsky)
Comment 9•13 years ago
|
||
Comment on attachment 583853 [details] [diff] [review]
Patch v1
Won't this possibly still pick up user.js values for this pref?
Assignee | ||
Comment 10•13 years ago
|
||
I thought lockPref() was supposed to prevent that?
Comment 11•13 years ago
|
||
I don't know. Does it take effect dynamically?
Assignee | ||
Comment 12•13 years ago
|
||
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...
Assignee | ||
Comment 13•13 years ago
|
||
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...
Assignee | ||
Comment 14•13 years ago
|
||
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.)
Assignee | ||
Updated•13 years ago
|
Attachment #583853 -
Attachment is obsolete: true
Attachment #583853 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 15•13 years ago
|
||
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 16•13 years ago
|
||
Comment on attachment 583883 [details] [diff] [review]
Patch v2
r=me
Attachment #583883 -
Flags: review?(bzbarsky) → review+
Comment 17•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Comment 18•13 years ago
|
||
Cool, thanks :)
Comment 19•7 years ago
|
||
Looks like it is an issue again. I don't see this setting in the Firefox 59
Comment 20•7 years ago
|
||
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.
Description
•