Open Bug 1443253 Opened 6 years ago Updated 11 months ago

WebExtensions: moz-extension files when loaded in iframes get content script scope/privileges


(WebExtensions :: Frontend, defect, P3)

58 Branch


(Not tracked)



(Reporter: jacobbarkdull, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: parity-chrome, testcase)


(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

1. Tried to open the sidebar from a click event.
2. Tried to get the background page from a click event.
3. Tried to open a new tab from a click event.

Actual results:

1. browser.sidebarAction is undefined.
2. browser.runtime.getBackgroundPage is not a function.
3. browser.tabs is undefined.

Expected results:

1. The sidebar to open.
2. An alert showing a message stored in main.js.
3. A new tab loading to open.

This problem is specific to Firefox, and does not occur in Chrome. I find problems like this difficult to explain with words, so I have attached an example extension that demonstrates the issue. There are two directories included in the attached ZIP file, one is the extension for Firefox and the other is the same extension for Chrome.
I forgot to mention: In the example extension attached, the page loaded in the iframe works when viewed by itself. You can test this yourself by doing a simple Context Menu -> This Frame -> Open Frame in New Tab. This should prove that the iframe is somehow the cause of the issue.
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Component: Untriaged → WebExtensions: Frontend
Keywords: testcase
Product: Firefox → Toolkit
I believe this bug should count towards bug 1161828, since it is specific to Firefox.
Whiteboard: [parity-chrome]
This is likely a WONTFIX.

The current behavior of Firefox is much like Chrome used to be.
The reason is that the extension frames in a tab are handled by a content process, whereas extension pages are handled by a privileged extension process.

Chrome supports out-of-process frames, so Chrome is able to render an extension frame in an extension process (and the iframe can safely be granted access to extension APIs - ).
In contrast, Firefox does not support out-of-process frames, so the iframe is handled by a non-extension process (with only limited access to extension APIs).

When you want to access extension APIs, you should send a message to the background page.
Unfortunately, cannot be called in this way because of the required user gesture (bug 1392624).
I can indeed confirm this with my WIP Shumway WebExtension port.
Ever confirmed: true
As Rob explained above, this is working as designed.
Closed: 6 years ago
Resolution: --- → WONTFIX
Shouldn’t we file a bug for implementing out-of-process frames and having this depend on it instead of WONTFIXing this?
Flags: needinfo?(tomica)
Flags: needinfo?(rob)
Depends on: oop-frames
Flags: needinfo?(tomica)
Flags: needinfo?(rob)
Resolution: WONTFIX → ---
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]
Product: Toolkit → WebExtensions
Closed: 6 years ago6 years ago
No longer depends on: oop-frames
Resolution: --- → DUPLICATE

This works now in latest Nightly.

Blocks: fission
Depends on: oop-frames

(In reply to ExE Boss from comment #11)

This works now in latest Nightly.

It does not work. This is not fixed. I just tested in Firefox Nightly 71.0a1 (2019-09-15) (64-bit).

Did you try the demo extension I provided?
The demo still behaves the same as it did when I submitted this bug report almost 2 years ago.
Whereas it continues to work perfectly in Chrome.

Perhaps there is a preference that I need to change before it will work?
If so, I don't think this bug should be marked as fixed until that preference is set that way by default.

Parts of fission have indeed landed in Nightly, but are currently behind a pref, and not yet ready for turning on by default.

Besides bug 1429896, functionality in this bug also depends on changes to Web Extension framework to adapt it for fission, which are being worked on in bug 1573488 and dependencies.

Additionally, this bug might not be part of the initial rollout of Fission for extensions, the main focus will be getting all existing extensions functionality working with Fission before adding new features that are enabled by it.

No longer blocks: fission
Depends on: fission-webext
Priority: -- → P3
Resolution: FIXED → ---

Thank you for clarifying for me Tomislav. I'm glad this is still being worked on and that it seems to be coming along nicely.

Blocks: oop-frames
No longer depends on: oop-frames
Blocks: fission-webext
No longer blocks: oop-frames
Depends on: oop-frames
No longer depends on: fission-webext

As described in comment 13, this doesn't need to block Fission (it is only enabled by Fission).

No longer blocks: fission-webext
Depends on: fission-webext
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.