Update on Compatibility Milestones

The Road to Firefox 57 has been updated with a couple of changes to the timeline:

  • Firefox won’t run in multiprocess mode unless all enabled add-ons have the multiprocessCompatible flag set to true or are WebExtensions. This means that developers who haven’t set this flag don’t have to worry about multiprocess compatibility and can focus on WebExtensions and the Firefox 57 deadline.
  • The multiprocess compatibility shims will be removed earlier, starting with the Nightly and Developer Edition channels. Their purpose was to ease the transition to multiprocess compatibility, but given the change in the previous point, they aren’t really needed anymore. Removing them will help track performance issues.

None of these changes should require any immediate action from developers, but let us know if you have any questions or concerns.

6 responses

  1. erosman wrote on :

    The availability of the APIs is the biggest hurdle.
    As a developer with a few very small addons, I have found out that:

    – 3 addons could be ported and were ported to WebExtension
    – 1 addon requires tab contextmenu which thankfully Firefox is ahead of other browsers as others don’t have it. It is supported from FF53
    – 1 addon was ported but with reduced functionality
    – 1 addon could not be ported due to lack of API (‘onRefreshAttempted’ from ‘addTabsProgressListener’)
    – 1 addon require filesystem read access and while there is a Google Chrome API (chrome.fileSystem), Firefox does not plan to implement it
    – 1 addon requires proxy and while there is a Google Chrome API (chrome.proxy), Firefox hasn’t yet put it on the timetable to implement

    1. Andy McKay wrote on :

      chrome.proxy is available in Firefox 55

  2. Nemo wrote on :

    I noticed that in Firefox 52, it’s not at all obvious which extensions might be responsible for disabling e10s. about:support lacks any information more specific than ‘0/1 (Disabled by add-ons)’. Even with the Add-on Compatibility Reporter extension installed, about:addons still shows that e.g. Click&Clean is ‘Not compatible with multiprocess,’ despite that it can be installed and enabled and Firefox starts up in e10s mode anyway.

    Is that related to this blacklist-instead-of-whitelist behavior that’s no longer part of the plan? It’s been a bit confusing, since about:support won’t say which addons are at fault for preventing e10s mode, so you’d have to disable them one by one to find out which.

    1. Jorge Villalobos wrote on :

      Yes, it’s likely because of whitelisting, which is an exception that bypasses the existing mechanisms.

  3. Yolanda Toler wrote on :

    I don’t like having to read this stuff

  4. md.delowar hossain wrote on :

    I noticed that in Firefox 52, it’s not at all obvious which extensions might be responsible for disabling e10s. about:support lacks any information more specific than ‘0/1 (Disabled by add-ons)’. Even with the Add-on Compatibility Reporter extension installed, about:addons still shows that e.g. Click&Clean is ‘Not compatible with multiprocess,’ despite that it can be installed and enabled and Firefox starts up in e10s mode anyway.,Is that related to this blacklist-instead-of-whitelist behavior that’s no longer part of the plan? It’s been a bit confusing, since about:support won’t say which addons are at fault for preventing e10s mode, so you’d have to disable them one by one to find out which.