Bug 1017320 (e10s-shims)

[e10s] [meta] Compatibility shims for add-ons

RESOLVED INVALID

Status

()

Firefox
Extension Compatibility
RESOLVED INVALID
4 years ago
10 months ago

People

(Reporter: billm, Unassigned)

Tracking

(Depends on: 1 bug, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

This bug is about running add-ons in a virtualized environment that will make e10s Firefox look more like single-process Firefox. Examples of this:

1. Accessing browser.contentWindow in normal Firefox code will be an error (even when e10s is enabled), while in an add-on it will return a cross-process wrapper around the content document.
2. Calling window.addEventListener("pageshow") from an add-on will send a request to all child processes asking that pageshow events be forwarded to the parent process so that they can be given to add-ons. Normal Firefox chrome code will never see these events, and they won't be forwarded unless add-ons ask for them.
3. Calling Services.obs.addObserver(..., "content-document-global-created", ...) will send a message to the child asking it to forward these observer notifications to the parent, similar to above.

Similar things will need to happen with the category manager and all the other places where an add-on can ask for notifications about activity in content.
tracking-e10s: --- → +
Keywords: meta
OS: Linux → All
Hardware: x86_64 → All
No longer depends on: 1040158
Depends on: 1062024

Updated

4 years ago
Depends on: 1061873

Updated

4 years ago
Depends on: 1058320

Updated

4 years ago
Alias: e10s-shims

Updated

4 years ago
Depends on: 690570

Updated

4 years ago
Depends on: 1098969

Comment 1

2 years ago
Who should we contact to can get a better understanding regarding the long term plan for the e10s shims? We have tried to use Nightly to assess the capabilities of the shims but it's stability prevents us from being able to draw any specific conclusions.

At a minimum, we would like to know more about:
1.	There is a reference (see https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox) to shims expiring “six month after multiprocess Firefox is released to users.” That statement is too vague because in theory you could say that multiprocess Firefox was released to users with FF 48, so it is not clear when the shims will be removed
2.	Is it the plan that shims will be able to support all use cases? If not, the sooner we know what the subset of use cases that won’t be supported the better off we will be.
3.	When will we be able to test our add-on using shims in a Firefox that is more stable than Nightly?

Any assistance will be greatly appreciated.

Comment 2

2 years ago
Steven,

2) See "Limitations of chrome scripts": https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts

3)

According to the Electrolysis Add-ons Schedule (https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule), multiprocess is planned to be enabled by default on the release channel with add-ons not marked compatible-without-shims starting from Firefox 51 (currently scheduled for 2017-01-24).

You can force-enable multiprocess in the current release channel by adding boolean browser.tabs.remote.force-enable to about:config and setting to true, then restarting Firefox.

Once multiprocess is enabled, "You can see all the places where your add-on uses compatibility shims by setting the dom.ipc.shims.enabledWarnings preference and watching the browser console as you use the add-on." (https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts)

Comment 3

10 months ago
With the move to WebExtensions, we'll be removing the shims and this bug is no longer valid.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.