Closed Bug 1214373 Opened 4 years ago Closed 10 months ago

Allow cross-origin access to iframes that an extension has permissions for

Categories

(WebExtensions :: General, defect, P3)

defect

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.
Flags: blocking-webextensions-
Whiteboard: triaged
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)
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)
That sounds good to me. I'll try to figure out how feasible it would be.
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: blocking-webextensions?
Priority: -- → P3
Duplicate of this bug: 1319201
Duplicate of this bug: 1332928
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.
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.
:andym, does this classify as chrome-parity issue per #c9 (i.e. blocking bug 1161828)?
Flags: needinfo?(amckay)
Sure.
Flags: needinfo?(amckay)
Version: 42 Branch → unspecified
(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.
(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.
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)
Flags: needinfo?(amckay)
Duplicate of this bug: 1412813
Flags: needinfo?(kmaglione+bmo)
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.
Product: Toolkit → WebExtensions
Fission will make this impossible.
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
No longer blocks: webextensions-chrome-gaps
You need to log in before you can comment on or make changes to this bug.