1374653 - For FF54, Legacy add-on forces restart but does not disable e10s until a second restart

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Steven Harris]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36

Steps to reproduce:

On a Windows system (specifically, Windows 7 or Windows 7 Professional):
1) Initiate the install of a legacy add-on into FF w/ e10s enabled - about:support, Multiprocess Windows: "1/1 (Enabled by default)"
2) The browser would download add-on, detect that it was a non-MPC compatible add-on and force a restart to complete installation


Actual results:

3) With FF54, after the restart, the add-on would be installed and Multiprocess Windows would be "1/1 (Enabled by default)"


Expected results:

3) Prior to FF54, after the restart, the add-on would be installed and Multiprocess Windows would be "0/1 (Disabled by add-ons)"

Comment 1

[Tracy Walker [:tracy]]

Steven, does Multiprocess get disabled if you restart a second time?  I observed what you reported above, then restarted again with the final result of e10s being disabled.  I believe I saw this being discussed in irc, but I am unable to find an existing bug on file.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I'm going to look into this.

Comment 3

[Steven Harris]

Tracy, interesting observation. We didn't actually explore that scenario.

What we did see was, following the initial restart to install the first legacy add-on, we would attempt to install a second legacy add-on, and after the subsequent restart, e10s would still be enabled.

Comment 4

[Tracy Walker [:tracy]]

I was able to reproduce this on Linux (Ubuntu 16.04) with release Firefox 54.0

I used this addon: https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-legacy/?src=search for testing.

What I noticed is that the add-on didn't show its UI until the second restart. 

Fortunately, on removal of the add-on, e10s is re-nabled on first restart.

Comment 5

[Tracy Walker [:tracy]]

Blake, I think you'll be able to reliably reproduce with above information.  Let me know if you need anything else here.

Comment 6

[:Paolo Amadini]

[Tracking Requested - why for this release]:
All legacy add-ons that are <em:multiprocessCompatible>false</em:multiprocessCompatible> are broken on Release when first installed, unless another incompatible add-on was previously installed. I just noticed this while testing the add-on I'm maintaining on a clean profile.

If the fix turns out to be simple, we may want to track this as a ride-along for a dot release.

I believe this should be tracked for Beta.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 54; let's see how this goes on beta before making a decision about a 54 dot release. If this is an uncommon scenario we probably don't want to fix it in 54.

Comment 8

[Gerry Chang [:gchang]]

Track 54+ per comment #6.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

The patch in bug 1372824 will fix this bug.

Comment 10

[Gerry Chang [:gchang]]

Mark 55 fixed as bug 1372824 was fixed in 55.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

...and on Nightly.