Closed
Bug 1214373
Opened 9 years ago
Closed 6 years ago
Allow cross-origin access to iframes that an extension has permissions for
Categories
(WebExtensions :: General, defect, P3)
WebExtensions
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ajtkmr, Unassigned)
References
Details
(Whiteboard: [berlin]triaged)
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151012151721 Steps to reproduce: Many add-ons including Distill Web Monitor need to open a page in the background and interact with the page. XUL based add-on can create browser elements to load such content and add-on sdk based add-ons can use page-worker module. It will be great to have a WebExtension API that lets extensions open such a page.
Updated•9 years ago
|
Flags: blocking-webextensions-
Updated•9 years ago
|
Whiteboard: triaged
Comment 1•8 years ago
|
||
We talked about this a few months ago. The consensus was that we don't want to add an extra API for this, but it should be supported via normal web APIs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-webextensions- → blocking-webextensions?
Summary: API to open and load a webpage in the background → Allow cross-origin access to iframes that an extension has permissions for
Whiteboard: triaged → [berlin]triaged
I'm actually wondering now how we should do this. The question is what sort of cross-compartment wrappers we would have. We probably want something like what we do for content scripts. But we have the added protection that content scripts have very limited browser.* APIs. In this case, a page with full browser.* APIs would have access to an external page. Kris, what do you think about allowing the load but requiring people to use a content script to manipulate the page?
Flags: needinfo?(kmaglione+bmo)
Comment 3•8 years ago
|
||
I think that probably makes sense. It would also help us avoid some issues with dead wrappers, and inner windows changing without the extension code noticing. I think this should already work, actually, to some degree. I have a couple of concerns, though: 1) We need to make sure it still works when we turn on CSP (bug 1254194). 2) We don't currently have any way to communicate with a content script that isn't running in a tab. Or, for that matter, to programmatically inject it into a sub-frame of the background page. So the content script would probably be able to send messages to a listener in the background page, and it should be able to respond, but it wouldn't be able to send messages directly to the background script. I don't really have a way to solve #2 within the constraints of the current APIs (except maybe hacking the tabs API to support accessing background pages using a special tab ID), so maybe we should go back to the original proposal, and add an API to load pages in a windowless browser?
Flags: needinfo?(kmaglione+bmo) → needinfo?(wmccloskey)
(In reply to Kris Maglione [:kmag] from comment #3) > 2) We don't currently have any way to communicate with a content script that > isn't running in a tab. Or, for that matter, to programmatically inject it > into a sub-frame of the background page. So the content script would > probably be able to send messages to a listener in the background page, and > it should be able to respond, but it wouldn't be able to send messages > directly to the background script. > > I don't really have a way to solve #2 within the constraints of the current > APIs (except maybe hacking the tabs API to support accessing background > pages using a special tab ID), so maybe we should go back to the original > proposal, and add an API to load pages in a windowless browser? Even if we add an API, I feel like we'll still need to solve these problems. Either way we want the added security of going through content scripts. Using an iframe just seems a little nicer to me. What if we allowed certain chrome.tabs APIs to operate on these frames? We would have a special tab ID, TAB_ID_BACKGROUND_PAGE or something, and then we would use the frame ID to reference an individual iframe. That feels like the most seamless approach to me.
Flags: needinfo?(wmccloskey)
Comment 5•8 years ago
|
||
That sounds good to me. I'll try to figure out how feasible it would be.
Updated•8 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: blocking-webextensions?
Priority: -- → P3
Not sure if this has been considered in CSP... can X-Frame-Options prevent loading a page in background iframe? Having parity with the TAB would be great for extension developers since it will let us use same pattern to interact with web content.
Blocks: webextensions-additional-apis
Comment 9•7 years ago
|
||
Note that this is something that's possible in Chrome extensions so even Chrome versions of some add-ons (like the mentioned Distill Web Monitor) won't be able to be ported to Firefox WebExtensions if this issue is not resolved.
Comment 10•7 years ago
|
||
:andym, does this classify as chrome-parity issue per #c9 (i.e. blocking bug 1161828)?
Flags: needinfo?(amckay)
Updated•7 years ago
|
Version: 42 Branch → unspecified
Comment 12•7 years ago
|
||
(In reply to Michał Gołębiowski [:mgol] from comment #9) > Note that this is something that's possible in Chrome extensions so even > Chrome versions of some add-ons (like the mentioned Distill Web Monitor) > won't be able to be ported to Firefox WebExtensions if this issue is not > resolved. The last I checked, this was definitely not possible in Chrome extensions.
Reporter | ||
Comment 13•7 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #12) > (In reply to Michał Gołębiowski [:mgol] from comment #9) > > Note that this is something that's possible in Chrome extensions so even > > Chrome versions of some add-ons (like the mentioned Distill Web Monitor) > > won't be able to be ported to Firefox WebExtensions if this issue is not > > resolved. > > The last I checked, this was definitely not possible in Chrome extensions. It is possible to load an external webpage in background page in an iframe. But it has a limitation that was alluded to in comment #8. If a webpage declares x-frame-options or enables csp, it may not be loaded in an iframe. It isn't as usable as it is to load pages in background in Firefox. If we could have a nice API to load and interact with content in background, it will be of great value to our users.
Comment 14•7 years ago
|
||
Forgive my dullness here, but I'm not absolutely clear on what this bug will accomplish. I have the following issue: Reading the following doc: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Cross-domain_privileges I get the impression that, using a content script, I should be able to get access to the document in a web page's iframe, even if the src for the iframe is in another domain, as long as I have provided sufficient permissions. I have a situation where I am trying to do just that, but am unsuccessful, with iframe.contentDocument == null. I can read other iframe's documents where the src is in the same domain. I have: "permissions": [ "<all_urls>"], set in my manifest. Will this bug fix my problem? Thanks...
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(amckay)
Updated•7 years ago
|
Flags: needinfo?(amckay)
Comment 16•7 years ago
|
||
Nag nag... I understand folks probably have a lot of stuff going on, but just wanted to pipe up here in case this is just buried in the land of forgotten. Having this fixed is pretty important for a couple of my addons.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Comment 17•6 years ago
|
||
Fission will make this impossible.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•5 years ago
|
No longer blocks: webextensions-chrome-gaps
Comment 18•2 years ago
|
||
Do we have any workaround to access cross-origin iframe content in a web extension content scripts
You need to log in
before you can comment on or make changes to this bug.
Description
•