extensions.e10sBlockedByAddons keeps resetting to 'true'

RESOLVED DUPLICATE of bug 1348576

Status

()

RESOLVED DUPLICATE of bug 1348576
2 years ago
2 years ago

People

(Reporter: post+mozilla, Unassigned)

Tracking

52 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170308012405

Steps to reproduce:

According to <https://wiki.mozilla.org/Firefox/AddOns/Status/current#Release_50_Details>, since Firefox 50, e10s should be enabled if all Addons I have installed are marked as compatible. I am now on Firefox 52. According to the "Add-on Compatibility Reporter", all my Addons (there's only three, plus the compatibility reporter) are indeed "compatible with multiprocess".


Actual results:

When I look at about:support, multiprocess is "Disabled by Add-ons". I can manually set extensions.e10sBlockedByAddons to false and restart Firefox to enable multiprocess, but when when I (un)install or enable/disable any addon, the setting switches back to true and multiprocess is disabled again.


Expected results:

I would expect multiprocess to automatically be enabled and to subsequently stay enabled. I would like to test and use multiprocess, but I do not want to "force" it for fear of compatibility problems.

It seems to me like either the documentation is wrong when it says that multiprocess will be enabled when all add-ons are compatible, or the add-on compatibility reporter is giving incorrect information about one of the add-ons, or some bug somewhere fails to properly implement the desired policy. Or maybe I am misunderstanding something?

Updated

2 years ago
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
(Reporter)

Comment 1

2 years ago
In case that's relevant, here's the Addons I have installed:
* Add-on Compatibility Reporter
* Expire history by days
* HTTPS Everywhere
* uBlock Origin

Comment 2

2 years ago
Hi, to help us debug this can you do the following:
1. Create the preference "extensions.logging.enabled" and set it to true (you can do this with a right-click and choose new -> boolean from about:config).
2. Restart the browser
3. Open the Browser Console (https://developer.mozilla.org/en-US/docs/Tools/Browser_Console), grab all the logs from browser startup, and put them in an attachment to this bug?
Flags: needinfo?(post+mozilla)
(Reporter)

Comment 3

2 years ago
Created attachment 8848927 [details]
Browser console log from startup (with extension logging enabled)
Flags: needinfo?(post+mozilla)

Comment 4

2 years ago
Sorry I wrote the steps above too hastily.  Can you do the same and gather logs during an operation that causes the preference to flip?
Flags: needinfo?(post+mozilla)
(Reporter)

Comment 5

2 years ago
Created attachment 8849640 [details]
Log from enabled the compaitiblity reporter addon

I had the compatibility reported add-on disabled and the pref enabled (and I restarted Firefox to get into a clean(er) state).  Then I hit "Enable" on the compatibility reporter addon.  Doing F5 in about:support claimed e10s was still enabled, but actually, I could see in about:config that the pref has already flipped to false.  Attached you can find the log from (I think) that operation.
Flags: needinfo?(post+mozilla)
(Reporter)

Comment 6

2 years ago
I just noticed I have another pref called "extensions.e10sBlocksEnabling" which is set to "true".  The line is *not* bold in about:config, so I assume this is the default and hence I will not touch it for now -- just letting you know in case this observation is relevant.

Comment 7

2 years ago
Hm, there are several of these message:
Add-on compatibility@addons.mozilla.org blocks e10s rollout.

What version of Addon Compatibility Reporter do you have?  Actually, can you paste in all the extension information from about:support?  Also cc'ing felipe, he knows this area much better...
Flags: needinfo?(post+mozilla)
(Reporter)

Comment 8

2 years ago
Extensions
Name 	Version 	Enabled 	ID
Application Update Service Helper	2.0	true	aushelper@mozilla.org
Expire history by days	1.2.1	true	expire-history-by-days@bonardo.net
HTTPS Everywhere	5.2.13	true	https-everywhere-eff@eff.org
Multi-process staged rollout	1.9	true	e10srollout@mozilla.org
Pocket	1.0.5	true	firefox@getpocket.com
uBlock Origin	1.11.4	true	uBlock0@raymondhill.net
Web Compat	1.0	true	webcompat@mozilla.org
Add-on Compatibility Reporter	2.2.3	false	compatibility@addons.mozilla.org
Flags: needinfo?(post+mozilla)

Comment 9

2 years ago
Felipe, I think I'm probably barking up the wrong tree here, can you take a look?
Flags: needinfo?(felipc)
Hi Ralf, can you give us the following info:

- Your distro and how did you obtain Firefox (through the distro package manager or downloaded from Mozilla's website?)

- The following settings from about:config (some might not exist):

browser.tabs.remote.autostart
browser.tabs.remote.autostart.2
extensions.e10s.rollout.policy
extensions.e10sBlocksEnabling
e10s.rollout.cohort
e10s.rollout.cohortSample
app.update.channel
Flags: needinfo?(felipc) → needinfo?(post+mozilla)
(Reporter)

Comment 11

2 years ago
I am using Debian testing amd64, and obtained Firefox via the distro package manager.  I can try using the official Firefox.

browser.tabs.remote.autostart: True (user set)
browser.tabs.remote.autostart.2: <does not exist>
extensions.e10s.rollout.policy: <does not exist>
extensions.e10sBlocksEnabling: True (default)
e10s.rollout.cohort: "unsupportedChannel" (user set)
e10s.rollout.cohortSample: 54 (user set)
app.update.channel: "default" (default)
Flags: needinfo?(post+mozilla)
Thanks. This is due to using the version from the package manager, which doesn't use "release" as the update channel. Fixing this is tracked at bug 1348576.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1348576
You need to log in before you can comment on or make changes to this bug.