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

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P3)

Description

[ajitk]

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.

Comment 1

[Kris Maglione [:kmag]]

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.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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?

Comment 3

[Kris Maglione [:kmag]]

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?

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(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.

Comment 5

[Kris Maglione [:kmag]]

That sounds good to me. I'll try to figure out how feasible it would be.

Comment 8

[ajitk]

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.

Comment 9

[Michał Gołębiowski-Owczarek [:mgol]]

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

[Johannes Pfrang [:johnp]]

:andym, does this classify as chrome-parity issue per #c9 (i.e. blocking bug 1161828)?

Comment 11

[Andy McKay]

Sure.

Comment 12

[Kris Maglione [:kmag]]

(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.

Comment 13

[ajitk]

(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

[u462496]

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...

Comment 16

[u462496]

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.

Comment 17

[Kris Maglione [:kmag]]

Fission will make this impossible.

Comment 18

[uppu.vinodkumar]

Do we have any workaround to access cross-origin iframe content in a web extension content scripts