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

RESOLVED DUPLICATE of bug 1429896

Status

defect
RESOLVED DUPLICATE of bug 1429896
2 years ago
4 months ago

People

(Reporter: jacobbarkdull, Unassigned)

Tracking

(Blocks 2 bugs, {parity-chrome, testcase})

58 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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 mozilla.org 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 - https://bugs.chromium.org/p/chromium/issues/detail?id=550151 ).
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, sidebarAction.open 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.

https://github.com/mozilla/shumway/issues/2435
https://github.com/ExE-Boss/mozilla-shumway/tree/web-extension
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 1451083
As Rob explained above, this is working as designed.
Status: NEW → RESOLVED
Closed: Last year
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)
Status: RESOLVED → REOPENED
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
Status: REOPENED → RESOLVED
Closed: Last year11 months ago
No longer depends on: oop-frames
Resolution: --- → DUPLICATE
Duplicate of bug: oop-frames
Duplicate of this bug: 1443264
Duplicate of this bug: 1542449
You need to log in before you can comment on or make changes to this bug.