Closed Bug 1405528 Opened 2 years ago Closed Last year

Add-ons that were previously uninstalled get re-installed and re-enabled when Firefox updates

Categories

(Firefox for Android :: Add-on Manager, defect)

All
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
fennec + ---
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 + verified
firefox63 --- verified

People

(Reporter: bruce.bugz, Assigned: rpl)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170914024831

Steps to reproduce:

1. Installed an add-on from AMO.
2. Uninstalled it.
3. Updated Firefox.

This happens for me on Nightly with all updates - the two add-ons that keep returning for me are 'Google search link fix' [1] and 'Google search link fix for Mobile and Desktop' [2]. Someone on Reddit ran into this issue on the stable branch too [3].

[1] https://addons.mozilla.org/en-US/android/addon/google-search-link-fix/
[2] developer has removed their add-on from AMO
[3] https://www.reddit.com/r/firefox/comments/743ok4/ff_56_addons_weirdness_android_os/


Actual results:

The uninstalled add-on is reinstalled.
Component: General → Add-on Manager
OS: Unspecified → Android
Hardware: Unspecified → All
So far I haven't looked at the respective code at all, but after poking around a bit in my profile, I have a suspicion that the migration logic from addons.json to extensions.json is doing this, which would explain why it's only happening after an app update.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Version: 58 Branch → unspecified
Given the report from [3] this probably has been happening for a few versions already.
I should add that I had uninstalled / reinstalled Nightly sometime back and I don't have this issue any more.

There was another Reddit thread about this yesterday: https://www.reddit.com/r/firefox/comments/7net8u/firefox_androids_extension_keeps_coming_back_even/
Actually my addons.json/extensions.json comment might have been a red herring - another thing I've observed is that the XPI files aren't deleted from the profile directory after uninstalling, so maybe after an update Firefox is rescanning the extensions directory and re-adding all those uninstalled add-ons back.

The problem is that it seems I can reproduce this only after restoring a backup with Titanium Backup, but not afterwards. So if e.g. I restore a complete backup I can reproduce it, but if I restore only the profile data from that backup and manually install the corresponding Firefox version I can already no longer reproduce it.

If that is indeed the case for what I've been seeing on my phone that leaves the question though how other people have been running into this bug then...
Hi Joe, Wesly
Maybe need to investigate more.
tracking-fennec: ? → +
Duplicate of this bug: 1435442
I don't think we have enough information to go on, here. David, do you want to keep this open or maybe close it INCOMPLETE?
Let's close it INCOMPLETE and re-open if something changes.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(ddurst)
Resolution: --- → INCOMPLETE
Duplicate of this bug: 1453875
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Start logcat - press Update on Play Store and wait for Nightly to install the update - open Nightly - open addon manager to verify the uninstalled extension came back - witness the problematic extension automatically open its developer website to congratulate - stop logcat.

https://pastebin.com/xRH4KFPq

In this case the extension that's returning is called User-Agent Switcher. Not to be confused with another extension called User-Agent Switcher (exact same naming) that I had installed earlier and never uninstalled. I don't think both extension having the same name is relevant because extensions with different names have re-installed themselves in past.

04-13 09:03:36.204 extension ef4ebf9d-9337-48e9-bd0f-3fa324a6e689 is the good User-Agent Switcher that was supposed to stay. 
04-13 09:03:34.006 extension a6c4a591-f1b2-4f03-b3ff-767e5bedf4e7 is the same good ef4ebf9d-9337-48e9-bd0f-3fa324a6e689 extension. In different places it has different moz- path IDs.


04-13 09:03:33.990 extension 75afe46a-7a50-4c6b-b866-c43a1075b071 , also known as a496c08a-222c-48f0-81f1-4cf22565d00b , is the problematic extension that reinstalled itself.
04-13 09:03:36.527  problematic extension is seen with an error.
04-13 09:03:41.065   is when the problematic extension opens its website after installing itself.

I can reproduce the problem with every Nightly update. Duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=1453875
I should mention that prior to experiencing the issue, few changes were made in the browser. I disabling all telemetry options under Privacy settings and restarted the LG G5 LineageOS 7.1.0 phone. 
Configured Firefox Nightly as the default Assist app under Android settings and used it at least once.
Earlier that day I disabled and re-enabled JavaScript in about:config, then configured uBlock Origin to block JavaScript on websites.
Sounds like this is still an issue. Can you help find someone to investigate further?
Flags: needinfo?(ddurst)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> Sounds like this is still an issue. Can you help find someone to investigate
> further?

Yes, it definitely seems to still be an issue.
I've been able to reproduce it locally (and it was also a consistent behavior from what I saw).

I'm redirecting the needinfo to me (I'm going to look into it in more detail asap)
Flags: needinfo?(ddurst) → needinfo?(lgreco)
OK, it would be good to know reliable STR and if this is only for particular extensions (and if so which ones they are or what they have in common) 

Oana, might you or someone on the mobile QA team be able to help with exploratory testing? Maybe, to check which versions are still affected.
Flags: needinfo?(oana.horvath)
I've tried to find reliable STR or extensions, but I could only reproduce it once (out of many tries) on Nightly, using the steps and extensions described in this bug and Bug 1453875.
Here are the steps I took, but they are not 100%:
1. Having Nightly (05-19-2018) installed, signed in to sync on an Android device and desktop. I used an old account that already had some data and other Android devices linked.
2. Installed the following add-ons: ublock, Google search link fix, User-agent switcher.
3. Synced.
4. Removed the "Google search link fix" add-on.
5. Updated Nightly from Google play.
The "Google search link fix" add-on was back.
Flags: needinfo?(oana.horvath)
This is not an easy one to trigger consistently, after being able to reproduce it twice in a row on my phone (one on "Nightly + Sync enabled", and one more time on "Stable + No Sync"), I've been trying to trigger it again on the emulator without any luck.

Nevertheless, I took a more deeper look at the code that may be involved into such issue, and I'm now able to reproduce it consistently, by forcing the scenario a bit:

STR
- install an older version of Firefox (I started by installing Fennec 55 on the emulator)
- enable more verbose AddonManager logging from about:config (extensions.logging.enabled = true)
- install an extension from AMO (e.g. uBlock)
- (copy the ublock xpi from the device, e.g. using adb pull /data/user/0/org.mozilla.firefox/files/mozilla/PROFILE_DIR/extensions/uBlock0@raymondhill.net.xpi .)
- open about:addons in a tab
- select the extension and click uninstall
- (copy the ublock xpi back to the device, e.g. using adb push, to recreate the conditions of "an extension removed from the listed extension, but the xpi file failed to be removed and it is still on disk", which I'm not still sure how/when it actually happens on its own without the need to manually force it)
- install a new version of Firefox (I installed Fennec 60 on the emulator using "adb install -r ...")
- wait the updated version to be installed successfully and load Firefox again
- load about:addons in a tab
- ublock is installed and listed again

Looking at the changes that we have introduced in the AddonManager and the XPIProvider components when the first version has been reported as affected, I think that "Bug 1391187 - Compare build id to perform a full startup directory scan" may be part of what started to trigger it, by introducing this new definition of gStartupScanScopes:

- https://searchfox.org/mozilla-central/rev/83a923ef7a3b95a516f240a6810c20664b1e0ac9/toolkit/mozapps/extensions/internal/XPIProvider.jsm#157-167

And that inline comment which says:

  "// If the build id changed, scan all scopes"

it is definitely ringing some bells.

And so, we do a "scan for changes" of the locations during the startup, when the profile is loaded for the first time with a new version we call XPIStates.scanForChanges(false) (where false is the ignoreSideload parameter):

- https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2453-2458,2478
- https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/toolkit/mozapps/extensions/internal/XPIProvider.jsm#1217

And that, with the help of the definition of gStartupScanScopes linked above, it is triggering a scan of the app-profile dir, looking for new xpi to install:

- https://searchfox.org/mozilla-central/rev/83a923ef7a3b95a516f240a6810c20664b1e0ac9/toolkit/mozapps/extensions/internal/XPIProvider.jsm#1241-1242,1250-1252,1254-1256

---------

Follows some extracts from the verbose logs collected while triggering the issue with the STR described above.

When the extension is uninstalled (and successfully removed from the list of the installed extensions):

- addons.xpi      DEBUG   Calling bootstrap method shutdown on uBlock0@raymondhill.net version 1.16.8
- addons.xpi      DEBUG   Calling bootstrap method uninstall on uBlock0@raymondhill.net version 1.16.8
- addons.xpi      DEBUG   Disabling XPIState for uBlock0@raymondhill.net
- addons.xpi      DEBUG   uninstallAddon: flushing jar cache /data/user/0/org.mozilla.firefox/files/mozilla/0iuu9apk.default/extensions/uBlock0@raymondhill.net.xpi for addon uBlock0@raymondhill.net
- addons.xpi      DEBUG   Removing XPIState for app-profile:uBlock0@raymondhill.net
- DeferredSave.extensions.json    DEBUG   Save changes
- addons.xpi      DEBUG   Removing XPIState for app-profile:uBlock0@raymondhill.net
- DeferredSave.extensions.json    DEBUG   Starting timer
- DeferredSave.extensions.json    DEBUG   Starting write
- DeferredSave.extensions.json    DEBUG   Write succeeded

Then once the new Firefox version is being started, the profile dir is checked for changes, the xpi file is found and the addon is being re-installed:

- Starting provider: XPIProvider
- addons.xpi      DEBUG   startup
- addons.xpi      INFO    SystemAddonInstallLocation directory is missing
- addons.xpi      INFO    Removing all system add-on upgrades.
- addons.xpi      DEBUG   checkForChanges
- addons.xpi      DEBUG   Loaded add-on state: {}
- addons.xpi      INFO    Mapping uBlock0@raymondhill.net to /data/user/0/org.mozilla.firefox/files/mozilla/0iuu9apk.default/extensions/uBlock0@raymondhill.net.xpi
- addons.xpi      DEBUG   New add-on uBlock0@raymondhill.net in app-profile
- addons.xpi      WARN    List of valid built-in add-ons could not be parsed.: 
- addons.xpi      DEBUG   getInstallState changed: true, state: {}
- addons.xpi      INFO    SystemAddonInstallLocation directory is missing
- addons.xpi-utils        DEBUG   Opening XPI database /data/user/0/org.mozilla.firefox/files/mozilla/0iuu9apk.default/extensions.json
- addons.xpi-utils        DEBUG   JSON schema mismatch: expected 24, actual 21
- addons.xpi-utils        DEBUG   Successfully read XPI database
- addons.xpi-utils        DEBUG   New add-on uBlock0@raymondhill.net installed in app-profile
Flags: needinfo?(lgreco)
Are you taking this on to fix it ? If not, can you help find an owner for this or let me know? Thanks.
Flags: needinfo?(lgreco)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #17)
> Are you taking this on to fix it ? If not, can you help find an owner for
> this or let me know? Thanks.

Yes, I've been looking into a proper fix.

When uninstalling an extension, the XPIProvider internals are already moving the file into a trash directory before removing it and despite that the issue seems to be still happening, and as described in Comment 16 I verified that with the current logic, if an xpi file is dropped in the profile extensions dir right before a Firefox upgrade, that xpi is going to be installed automatically.

From my current point of view, a reasonable fix seems to be to just avoid to collect any new sideload from a directory where Firefox is downloading/installing/uninstalling/removing xpi files on its own (like the profile's extensions dir, e.g. because there are actual chances that the file remove fails and they are going to be wrongly detected as new sideloads). 

And so an idea could be to add into XPIStates.scanForChanges an additional check to skip the locations that are "not locked" from the "scan for new sideloads":

```
      if (ignoreSideloads && !(loc.scope & gStartupScanScopes)) {
        continue;
      }

      if (loc.isTemporary) {
        continue;
      }

      if (!loc.locked) {
        // Do not collect sideloads from locations that are not locked,
        // otherwise if an installed extensions fails to be completely
        // uninstalled and the file stays in the original directory,
        // it will be re-installed when Firefox upgrades between
        // released versions and/or Nightly builds (See Bug 1405528).
        logger.debug("Do not scan ${loc} for new sideloads", {loc: loc.name});
        continue;
      }
```

Based on the XPIProvider internals, a location with location.locked == true should be a install location where Firefox is going to refuse to "download/install/uninstall/remove" files, on the contrary "locked" locations should just be a source of new extension that the user may choose to enable (and so "safe to scan for new sideloads", without risking to load by mistake an XPI file that Firefox failed to remove from disk when it got uninstalled by the user).

Unfortunately the above change currently breaks a good number of the AddonManager tests, that expect to be able to put xpi files in the profile’s extensions dir and have them installed (which is an assumption that the fix would actually break), and so (before planning to fix this assumption in the tests) I'm wondering if there are actual reasons (I mean "real world scenarios") why we would want/expect this behavior.

:aswan, are there any actual reasons to let any xpi file that has been put into the profile's extension dir (without being explicitly installed) to be automatically detected and installed by the AddonManager? (besides the testing purpose).

and as a more specific question: 
"browser_extension_sideloading.js" is currently testing some behaviors around sideloaded extensions by putting the sideloads' xpi files into the profile's extensions directory, is this a behavior that we expect from the real browser?
(based on the docs we have on MDN for the addon sideloading, it doesn't seem to be how it should actually work for real, but more a shortcut used in the tests, am I wrong?)
Flags: needinfo?(aswan)
I am mildly surprised that it isn't documented on MDN but I sideloading by dropping extensions into the profile is a widely used technique that I don't think we can just change.  I'm not clear on the underlying issue here, are files failing to be moved/removed for some reason, so they re-appear as sideloaded after being uninstalled?
Flags: needinfo?(aswan)
I'm not blocking beta 62 on this issue, but it sounds like something we should fix as early as possible in the 62 beta cycle. If it is a new regression in 62 we may want to treat this as a release-blocking issue.
Flags: needinfo?(ddurst)
I've been discussing about this with :aswan during the All Hands, and we agreed that the safest strategy would be to ensure that any xpi file found during the "full scan for changes" that is currently done when the application is upgrading (e.g. when the build id changes because a new nightly version is being installed, or when Firefox is upgrading between a previous released version to the new one) is going to be disabled by default on Fennec as it happens on Firefox Desktop.

In Firefox Desktop what makes these "foreign installed XPIs" to be disabled by default is the "extensions.autoDisableScopes" preference (https://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#56-58), and currently it doesn't seem to have a default value set on Fennec. 

"extensions.autoDisableScopes" has been introduced by Bug 693743, which has also the interesting summary "3rd party add-on check doesn't disable those add-ons on start-up, if they were installed into the profile or application folder".

I've verified that setting the default value of the "extensions.autoDisableScopes" preference on Fennec to the same value it has on Firefox Desktop prevents at least to auto-enable those extensions, which seems definitely better than how it currently behaves on Fennec (where the XPIs found are enabled without any prompt) and it makes Fennec to behave consistently to Firefox Desktop (where they are installed but disabled by default as any other detected sideloaded XPI).

It is also a change that would less likely introduce new regressions.
Flags: needinfo?(lgreco)
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

Hi Dave,
as I described in comment 21, it seems that the issue that Fennec is currently triggering is not so different from the one that Bug 693743 fixed long time ago on Firefox Desktop.

It is not clear yet why the installed XPIs sometimes fails to be removed on Android[1], nevertheless on Firefox Desktop such scenario would just result in extensions listed as "disabled by default sideloaded extensions", while on Fennec they are currently installed and then enabled by default (without any prompt).

The attached patch is going to set the default value of the "extensions.autoDisableScopes" preference to the same value used as default on Firefox Desktop, which seems the safest options to make Fennec to behave consistently with Firefox Desktop (and with a pretty low risk of introducing new regressions), and I can't currently think of any reasons why "extensions.autoDisableScopes" default value should not be the same as the one used in Firefox Desktop.

Aswan is currently PTO, do you mind to take a look at the proposed fix? (or redirect to someone that can take a look at it during this week)

[1]: it looks like an issue likely related to the filesystems used on the android phones, unfortunately it is pretty difficult to trigger this issue consistently, but it is definitely happening, I've been able to trigger it on my non-rooted android phones a couple of times, but never of the emulator
Attachment #8986163 - Flags: review?(dtownsend)
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

This seems to just wallpaper over the actual issue, these add-ons will still show up in the add-ons manager as disabled which seems likely to be confusing for users. I think someone more formally on the add-ons team like Kris should do the review here if this is what you really want. I might suggest that you add some telemetry to see if we can understand how often this problem is occurring.
Attachment #8986163 - Flags: review?(dtownsend)
(In reply to Dave Townsend [:mossop] from comment #24)
> Comment on attachment 8986163 [details]
> Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as
> they are on Firefox Desktop.
> 
> This seems to just wallpaper over the actual issue, these add-ons will still
> show up in the add-ons manager as disabled which seems likely to be
> confusing for users. 

I don't consider attachment 8986163 [details] as a complete fix for the "uninstalled addon gets re-installed when Fennec updates" issue, but it worries me that the issue is actually worst on Fennec because the addon is also enabled by default and it doesn't show any permission prompt.

As it behaves right now, it is basically a vehicle for unexpected silent sideloads (and the user may even not notice it, if the addon is "silent" and the user never goes to about:addons).

Both the behaviors ("installed and enabled", or "installed but disabled by default") are likely to be confusing to the user, but the current one seems worst to me (and potentially harmful). 

> I think someone more formally on the add-ons team like
> Kris should do the review here if this is what you really want. 

Yeah, I've been discussing about this with aswan during the past weeks (and this was basically the first step that we agreed on when we looked at this together during the All Hands).

I'll try to discuss about this with Kris before the end of the week, otherwise I'll keep evaluating it with aswan once he is back from PTO next week.

> I might suggest that you add some telemetry to see if we can understand how often
> this problem is occurring.

Sure, I definitely agree, some telemetry data may be useful to get some additional info about its incidence (e.g. I'm thinking about sending a telemetry event when an extension xpi file seems to have been already removed while the uninstall code is removing it, https://searchfox.org/mozilla-central/rev/d0a41d2e7770fc00df7844d5f840067cc35ba26f/toolkit/mozapps/extensions/internal/XPIInstall.jsm#2974, `Attempted to remove ${aId} from ${this.name} but it was already gone` is a warning message that seems to be part of the logs I collected every time I've successfully triggered this issue on my android phones).
Assignee: nobody → lgreco
Removing my NI, but noting here (for the casual drivers-by that might be), an extension that should be removed (from the filesystem) is not being removed; and as such is being re-included by a scan that we still want to have happen.

Finding out what the removal isn't sticking on Android is the open issue -- and hopefully that can be fixed during 62 beta.
Flags: needinfo?(ddurst)
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

Hi Andrew,
do we want to proceed as we agreed during our last brief discussion on this topic and set the default value of the "extensions.autoDisableScopes" preference on Fennec to the same default value it has on Firefox Desktop?

This way, if any XPI file is being found in the profile's extension dir, it is still going to be listed, but at least they would be disabled by default, as they are on Firefox Desktop.

Besides that, I think that we should also file on bugzilla some additional followups to look for a more complete and long term solution for the underlying issues, e.g.:

- "Investigate why XPI files related to uninstalled addons are not always removed on Android", with the goal of figuring out the reason why Fennec is not always able to remove these XPI files (which seems to be a platform specific issue)

- "Reduce the scope of the full XPI scan on upgrades" (which is not a platform specific issue, we don't scan the profile extension dir for sideloads during normal startups and so I'm still wondering if we could reduce the scope of the scan we do on Firefox upgrades, which seems that Bug 1391187 has made broader than it was before, we should still do a full scan of all the locations if the XPI database/state files get corrupted, but it doesn't seem right to do the same kind of scan on every Firefox upgrades).
Attachment #8986163 - Flags: review?(aswan)
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

https://reviewboard.mozilla.org/r/251600/#review260722
Attachment #8986163 - Flags: review?(aswan) → review+
(In reply to Luca Greco [:rpl] from comment #27)
> Besides that, I think that we should also file on bugzilla some additional
> followups to look for a more complete and long term solution for the
> underlying issues, e.g.:

We certainly need to keep tracking this.  I would vote for either setting leave-open on this bug or creating a new bug to land the autoDisableScopes change but whatever you prefer.
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/50c10bf4d10f
Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop. r=aswan
Luca is this something you think is safe, or risky, to uplift to beta?
Flags: needinfo?(lgreco)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #32)
> Luca is this something you think is safe, or risky, to uplift to beta?

Hi Liz,
it should not be risky, and pretty safe to uplift to beta.

The change that we landed is actually only applied on the mobile preferences, and it sets the same default value that is already used on Firefox Desktop from a long time (its effect is to just auto-disable by default any new xpi file that is found during a full scan of the supported install locations).
Flags: needinfo?(lgreco)
OK, can you request uplift? Thanks!
Flags: needinfo?(lgreco)
And to make things more clear for relman, sheriffs, and QA can you file a new bug for the remaining issue? That way we know that something landed here that might get uplifted and need testing.... but then we can track the new bug separately.
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

Approval Request Comment

[Feature/Bug causing the regression]:

Bug 1391187 seems to be the change that triggered an "Addon Manager full scan" on any startup related to a Firefox update, even if only the buildID has been changed.

[User impact if declined]:

Any xpi file found in the scanned location is installed and enabled automatically (and on Firefox for Android, for reasons that we have not been able to track down yet, it seems that sometimes the xpi files for the uninstalled add-ons are not being removed from the filesystem, and so they get automatically re-installed and re-enabled on the next Firefox for Android update).

[Is this code covered by automated tests?]:

The patch doesn't directly change the implementation, it changes the default value of an existing about:config preference to the same default value already used on Firefox Desktop. The about:config preference is internally used by the AddonManager code, which is covered by a good number of existing automated tests.

[Has the fix been verified in Nightly?]:

it has not been explicitly verified by QA

[Needs manual test from QE? If yes, steps to reproduce]:

yes, it would be helpful, the issue is not easy to be triggered consistently, as also mentioned by QE in comment 15, but it can be triggered on a rooted device (where you can copy an xpi file manually in the expected location) by using an STR like the one from comment 16.

[List of other uplifts needed for the feature/fix]:

None

[Is the change risky?]:

No, it should be very low risky

[Why is the change risky/not risky?]:

The attached patch sets the default value of "extensions.autoDisableScopes" to the same default value used on Firefox Desktop for a long time and, as described in a bit more detail in comment 27, with this default value Firefox disables by default any xpi file that is found during a full scan, as it currently does on Firefox Desktop if the same scenario is met.

[String changes made/needed]:

None
Attachment #8986163 - Flags: approval-mozilla-beta?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #35)
> And to make things more clear for relman, sheriffs, and QA can you file a
> new bug for the remaining issue? That way we know that something landed here
> that might get uplifted and need testing.... but then we can track the new
> bug separately.

Sure, sounds reasonable to me too (and I'm not clearing the needinfo, so that I'll get back to this asap). 

I'll file a new bug and reference this one in it (because this issue provides a lot of additional context and an initial analysis about what is going on and it may be useful to work on the remaining issue, that is mainly "why the xpi file fails to be removed on Android"), and I should probably also tweak the summary of this bugzilla issue a bit (to better describe the actual actions that we took here, e.g. even just re-phrase it to "Add-ons that were previously uninstalled get reinstalled and enabled when Firefox updates").
Flags: qe-verify+
Andrei can your team verify this issue with the STR in comment 36? I am going to go ahead and uplift now anyway. But it would be good to confirm this in nightly.
Flags: needinfo?(andrei.vaida)
Comment on attachment 8986163 [details]
Bug 1405528 - Sideloaded XPIs should be disabled by default on Fennec as they are on Firefox Desktop.

This has some duplicate reports so while it may not be a recent regression I take it that it bothers a significant amount of users. Let's uplift for beta 15.
Attachment #8986163 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Tested on Nightly (63.0a1), following the steps provided in comments with Nokia 6(Android 7.1.1) and Nexus 5(Android 6.0.1) and I wasn't able to reproduce the issue. We installed/uninstalled different add-ons and update the build in order to see if the addons were listed again and everything worked as expected.
Flags: qe-verify+
Flags: needinfo?(andrei.vaida)
Marking the status-firefox62: fixed, based on comment 40.
Hi Jan,

Is the regressionwindow-wanted flag still valid, considering Comment 40?

Thank you?
Flags: needinfo?(jh+bugzilla)
I guess not.
Flags: needinfo?(jh+bugzilla)
Fix landed in 63, QE confirmed it works in comment #41 in 62 and 63. Updating tracking flag. Should that bug remain open?
(In reply to Pascal Chevrel:pascalc from comment #45)
> Fix landed in 63, QE confirmed it works in comment #41 in 62 and 63.
> Updating tracking flag. Should that bug remain open?

I just filed Bug 1491814 as a follow up for the remaining issues from this bug (which is basically: investigate why the xpi files are not always removed, and fix it so that we can also avoid to reinstall the related addon), so that we can close this one.
Status: REOPENED → RESOLVED
Closed: 2 years agoLast year
Flags: needinfo?(lgreco)
Resolution: --- → FIXED
See Also: → 1491814
Summary: Add-ons that were previously uninstalled get reinstalled when Firefox updates → Add-ons that were previously uninstalled get re-installed and re-enabled when Firefox updates
Marking the flags 62 and 63 as verified, based on comment 41.
Target Milestone: --- → Firefox 63
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.