Closed Bug 1017320 (e10s-shims) Opened 6 years ago Closed 3 years ago
[e10s] [meta] Compatibility shims for add-ons
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.
Depends on: 1017323
Depends on: 1029202
Depends on: 1029248
Depends on: 1029926
Depends on: 1031608
Depends on: 1031609
Depends on: 1040158
No longer depends on: 1040158
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.
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)
With the move to WebExtensions, we'll be removing the shims and this bug is no longer valid.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.