728466 - [ACR] Restarting during application startup locks the database and forces the user to re-allow all add-ons.

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Compatibility Tools, defect, P1)

Description

[Dave Townsend [:mossop]]

From bug 702506 comment 20:

1) Create fresh profile
2) Set up Sync against existing profile that has add-ons
3) Wait for initial sync run to complete. See entries in about:addons
4) Restart browser
5) On restart witness new tabs opened by add-on install, new chrome in browser
6) Go to about:addons and see the "You don't have of this type installed" message
7) Restart browser a few times
8) Get a bunch of about:newaddon tabs

This is only a problem when ACR is included in the set of add-ons synced.

Comment 1

[Brian King [:kinger]]

So short of backing out the restart fnctionality in ACR, is there any other possible workarounds? For example, is there any event at startup to listen for to know we have just been synced?

Comment 2

[Richard Newman [:rnewman]]

(In reply to Brian King (Briks) [:kinger] from comment #1)
> So short of backing out the restart fnctionality in ACR, is there any other
> possible workarounds? For example, is there any event at startup to listen
> for to know we have just been synced?

Sync doesn't emit one, certainly. (Sync won't even be initialized completely until ten seconds after Firefox launches.)

It will emit notifications during and after the syncing process itself, but I would kinda raise my eyebrows if this kind of cycle of observers and tracking was the best solution.

gps can speak more about what information is known by the add-ons engine.

Comment 3

[Brian King [:kinger]]

Actually, given that ACR no longer enables add-ons (in CBD builds), I think the only thing to do here is to rip out the restart feature. I'm not sure why it was overlooked when we turned off anabling.

I'll have a new build tomorrow to (re-)test with.

Comment 4

[Brian King [:kinger]]

Fixed in production repos, r101990.

Comment 5

[Brian King [:kinger]]

Test build (1.1b1):

http://briks.si/misc/acr/acr.xpi

If your happy enough this fixes it, I'll remove beta from the version and upload it to AMO.

Comment 6

[Gregory Szorc [:gps]]

This won't be easy to verify before launch from the perspective of Sync. Sync installs add-ons via AMO. So, to test this, I'd need to set up a stub AMO server and point a Sync client at that. Or, perhaps there is some voodoo I can do with the extensions database to have the XPI cached.

If ACR is pushed to AMO, I can verify it works with Sync easily enough.

Comment 7

[Dave Townsend [:mossop]]

(In reply to Gregory Szorc [:gps] from comment #6)
> This won't be easy to verify before launch from the perspective of Sync.
> Sync installs add-ons via AMO. So, to test this, I'd need to set up a stub
> AMO server and point a Sync client at that. Or, perhaps there is some voodoo
> I can do with the extensions database to have the XPI cached.

We have staging instances of AMO that you should be able to put specific add-ons onto and point Firefox at through prefs. Fligtar or Jorge should be able to point you in the right direction.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

Brian should be able to upload the update to our test site: https://addons-dev.allizom.org/en-US/firefox/.

If the Sync pref can be modified to point to it, testing should be possible.

Comment 9

[Brian King [:kinger]]

I'll upload to AMO today anyway because a) it is a necessary fix from an ACR perspective as well b) low-risk and c) other changes have gone in warranting a new release.

Comment 10

[Brian King [:kinger]]

1.1 is now live, or at least will be once it gets past the site cache.

https://addons.mozilla.org/addon/add-on-compatibility-reporter/

Comment 11

[Alex Keybl [:akeybl]]

Adding qawanted to verify that the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=728466#c0 no longer cause a user's add-ons to be disabled.

Comment 12

[u279076]

(In reply to Alex Keybl [:akeybl] from comment #11)
> Adding qawanted to verify that the STR in
> https://bugzilla.mozilla.org/show_bug.cgi?id=728466#c0 no longer cause a
> user's add-ons to be disabled.

For reference:

> 1) Create fresh profile
> 2) Set up Sync against existing profile that has add-ons
> 3) Wait for initial sync run to complete. See entries in about:addons
> 4) Restart browser
> 5) On restart witness new tabs opened by add-on install, new chrome in browser
> 6) Go to about:addons and see the "You don't have of this type installed" message
> 7) Restart browser a few times
> 8) Get a bunch of about:newaddon tabs
> This is only a problem when ACR is included in the set of add-ons synced.

Comment 13

[Gregory Szorc [:gps]]

I'm not QA, but I didn't see the issue. I only tried with a single profile, however.

Comment 14

[u279076]

Tested this with Firefox 11.0b4 on Windows 7 64-bit without issues. I had the following add-ons installed:
 * Adblock Plus
 * Aniweather
 * ReminderFox
 * TabMix Plus
 * and ACR
(all latest versions available on AMO)

All add-ons were still enabled after sync. Removing qa-wanted -- please add if there is something more that is needed.

Comment 15

[Brian King [:kinger]]

I dare say we are fixed here then. Thanks for the QA.