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

NEW
Unassigned
(NeedInfo from)

Status

()

Toolkit
WebExtensions: General
P3
normal
2 years ago
4 days ago

People

(Reporter: ajitk, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [berlin]triaged)

(Reporter)

Description

2 years ago
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

2 years ago
Flags: blocking-webextensions-

Updated

2 years ago
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.

Updated

a year ago
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: blocking-webextensions?
Priority: -- → P3
Duplicate of this bug: 1319201
Duplicate of this bug: 1332928
(Reporter)

Comment 8

9 months ago
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.

Updated

7 months ago
Blocks: 1215059
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)

Comment 11

3 months ago
Sure.
Flags: needinfo?(amckay)
Blocks: 1161828
No longer blocks: 1215059
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.
(Reporter)

Comment 13

2 months 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

6 days 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

4 days ago
Flags: needinfo?(amckay)
You need to log in before you can comment on or make changes to this bug.