Open
Bug 944414
Opened 12 years ago
Updated 3 years ago
xul <browser> element should not care for x-frame-options
Categories
(Core :: DOM: Security, defect)
Core
DOM: Security
Tracking
()
UNCONFIRMED
People
(Reporter: delrue.jonas, Unassigned)
Details
(Whiteboard: [domsecurity-backlog])
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018
Steps to reproduce:
Added this to a xul file:
<browser type="content.primary" src="http://www.facebook.com" flex="1"> </browser>
Actual results:
Nothing was loaded, error shown "Load denied by X-Frame-Options: https://www.facebook.com/ does not permit framing."
Expected results:
I should see the website. A Browser should be able to go to every website, an <iframe> does not. This is similar to <webview> (chromium) and <x-ms-webview> (windows). When reading this: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI it is very clear that this is unexpected behavior.
Comment 1•12 years ago
|
||
(In reply to delrue.jonas from comment #1)
> Added this to a xul file:
> <browser type="content.primary" src="http://www.facebook.com" flex="1">
> </browser>
Is content.primary a typo? If not, you want "content-primary", see the documentation below.
> When reading this:
> https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI it is very clear that
> this is unexpected behavior.
But you're using a XUL <browser>, which is documented on https://developer.mozilla.org/en-US/docs/XUL/browser#a-browser.type .
Updated•12 years ago
|
Flags: needinfo?(delrue.jonas)
Reporter | ||
Comment 2•12 years ago
|
||
It is indeed a typo but doesn't influence the result. Retested it with content-primary and the result is the same. I know I'm using a XUL browser but the link I posted mentions the XUL browser as an example for this functionality. Even the example on your link (<browser type="content" src="http://www.mozilla.org" flex="1"/>) doesn't work because of X-Frame-Options.
Flags: needinfo?(delrue.jonas)
Reporter | ||
Updated•12 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Reporter | ||
Updated•12 years ago
|
Summary: <browser> element should not care for x-frame-options → xul <browser> element should not care for x-frame-options
Reporter | ||
Updated•12 years ago
|
Version: 25 Branch → Trunk
![]() |
||
Updated•11 years ago
|
Component: Untriaged → DOM: Security
Product: Firefox → Core
Updated•10 years ago
|
Comment 4•9 years ago
|
||
Gijs, should we reinvestigate what's happening here or can we close this bug?
Flags: needinfo?(gijskruitbosch+bugs)
Whiteboard: [domsecurity-backlog]
Comment 5•9 years ago
|
||
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #4)
> Gijs, should we reinvestigate what's happening here or can we close this bug?
I have no idea about the implementation of X-Frame-Options, and/or if the xul file from comment #0 would have been privileged or not - it's clear that you can load facebook in a browser content view, so I don't know why it wouldn't work, without more details. Who knows about X-Frame-Options?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mozilla)
Comment 6•9 years ago
|
||
Steve, I know Sid used to work on x-frame-options. Do you know if someone is still doing any active work on this, and if so, who is it?
Flags: needinfo?(mozilla) → needinfo?(sworkman)
Comment 7•9 years ago
|
||
I'm not aware of any active work on x-frame-options, Chris, sorry. Might need to do a bit of bug archeology here.
Flags: needinfo?(sworkman)
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•