Closed Bug 1246245 Opened 4 years ago Closed 4 years ago
Webextensions and themes should also block e10s
1) Start Firefox with a clean profile 2) Access addons.mozilla.org and select and add-on from the Newest or Recently Added - Specifically select Wachete - Monitor website content changes Ver 1.3 3) Access about:addons and ensure Extensions displays the add-on you installed 4) Access about:config and add browser.tabs.remote.autostart.2 = true 5 In about:config add extensions.e10sBlocksEnabling = true 6) Restart Firefox Expectation: A) browser.tabs.remote.autostart.2 = true B) extensions.e10sBlockedByAddons = true C) extensions.e10sBlocksEnabling = true D) Multiprocess windows in about:support is 0 [ 0/1 (default: false)] Actual: Multiprocess Windows 1/2 (default: true) extensions.e10sBlockedByAddons = false extensions.e10sBlocksEnabling = true [Restart with Add-on Disabled] 1) Perform the steps to install Wachete 2) Access about:addons and ensure Extensions displays the add-on 3) Access about:support 4) Click the button Restart with Add-ons Disabled 5) Click Restart 6) Click Start in Safe Mode Expectation: A) browser.tabs.remote.autostart.2 = true B) extensions.e10sBlockedByAddons = true C) extensions.e10sBlocksEnabling = true D) Multiprocess Windows 0/1 (default: false) E) Safe Mode true Actual: Multiprocess Windows 2/2 (default: true) extensions.e10sBlockedByAddons = false extensions.e10sBlocksEnabling = true This is occurring in 45.0b2 and 45.0b3 Platforms tested Windows 10, Windows 8.1, Windows 7, Windows XP, Ubuntu 14.04, Mac 10.11
Michelle, can you reproduce this issue while setting the pref in (5), before installing the add-on? And did you try the same steps with other add-ons, and the issue here occurs with only this one?
@Felipe: Correct. I can set the prefs "browser.tabs.remote.autostart.2 = true" and "extensions.e10sBlocksEnabling = true" and "extensions.e10sBlockedByAddons = false" Next confirm the setting remain as input after a restart is a Pass. Access about:addons and install the Wachete add-on. The results are the same, Multiprocess remains enabled and the extensions.e10sBlockedByAddons remains false. Also Yes: I have asked the testers to vary the add-ons daily, while a few add-ons remain constant we do vary the Collection, Recently Added,etc... So far this is the only one we have found that causes this anomaly.
Probably all Web Extensions. I just found first one listed that is a web extension under new (not knowing any or having found a better way to find one other than source examples.) https://addons.mozilla.org/en-GB/firefox/addon/datascrapper Only need to look at extensions.e10sBlockedByAddons, it updates live in about:config with restart-less extensions.
Ah, that's a very good catch! Thanks Michelle for reporting it and Jonathan for figuring it out. Michelle, that's expected. There's a class of add-ons that don't need to block e10s, and this is one of them. I don't know if there is a easy way to tell them apart, but I'll look into it
Ok, it was decided that these types of add-ons should also block the initial e10s rollout
Assignee: nobody → felipc
Status: NEW → ASSIGNED
Summary: Wachete Add-on ignores prefs for E10s and Add-on Blocking → Webextensions and themes should also block e10s
Comment on attachment 8718335 [details] [diff] [review] patch Review of attachment 8718335 [details] [diff] [review]: ----------------------------------------------------------------- Even more surprised we're doing this for themes too
Bill mentioned that one of the crashes that we saw in the first experiment, bug 1210099, is something that could be triggered by a webextension as well. So to reduce risk in the initial rollout, Blassey asked that only totally clean profiles would get it (and that's why I also included heavyweight themes). Hopefully we'll lift the restriction, or parts of it, in the next version after shipping.
Comment on attachment 8718335 [details] [diff] [review] patch Approval Request Comment [Feature/regressing bug #]: expands coverage of e10s block for add-ons of type "webextensions" and "themes" [User impact if declined]: some users might not be blocked from the first e10s rollout [Describe test coverage new/current, TreeHerder]: shipped on nightly, feature is covered by tests [Risks and why]: very small, just expands the list of types in the code that is already in the tree [String/UUID change made/needed]: none
Attachment #8718335 - Flags: approval-mozilla-aurora?
[Tracking Requested - why for this release]: wanted for e10s on 46
Great, thanks. I was just about to ask about this from discussion on another bug.
Comment on attachment 8718335 [details] [diff] [review] patch This will slightly narrow the users we ship e10s to, to avoid crashes. Please uplift to aurora.
Attachment #8718335 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
[bugday-20160323] Status: RESOLVED,FIXED -> VERIFIED Comments: Test Successful Component: Name Firefox Version 46.0b9 Build ID 20160322075646 Update Channel beta User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 OS Windows 7 SP1 x86_64 Expected Results: Yes Actual Results: As expected
You need to log in before you can comment on or make changes to this bug.