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

Status: REOPENED

(WebExtensions :: Frontend, defect, P3)

Description

[Jacob Barkdull]

Attachment: An example extension that demonstrates the issue.

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.

Comment 1

[Jacob Barkdull]

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.

Comment 2

[Jacob Barkdull]

I believe this bug should count towards bug 1161828, since it is specific to Firefox.

Comment 3

[Rob Wu [:robwu]]

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

Comment 4

[ExE Boss]

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

Comment 5

[Tomislav Jovanovic :zombie]

As Rob explained above, this is working as designed.

Comment 6

[ExE Boss]

Shouldn’t we file a bug for implementing out-of-process frames and having this depend on it instead of WONTFIXing this?

Comment 7

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 11

[ExE Boss]

This works now in latest Nightly.

Comment 12

[Jacob Barkdull]

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

Comment 13

[Tomislav Jovanovic :zombie]

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.

Comment 14

[Jacob Barkdull]

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.

Comment 15

[Tomislav Jovanovic :zombie]

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