The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in ACR-1.1

Status

addons.mozilla.org Graveyard
Compatibility Tools
P1
critical
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: mossop, Assigned: kinger)

Tracking

unspecified
ACR-1.1
x86_64
Windows 7
Dependency tree / graph

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Blocks: 712542
(Assignee)

Comment 1

5 years ago
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?
Assignee: nobody → briks.si
Priority: -- → P1
Target Milestone: --- → ACR-1.1
(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.
(Assignee)

Comment 3

5 years ago
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.
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

5 years ago
Fixed in production repos, r101990.
(Assignee)

Comment 5

5 years ago
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

5 years ago
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.

Updated

5 years ago
tracking-firefox11: --- → +
(Reporter)

Comment 7

5 years ago
(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.
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.
(Assignee)

Comment 9

5 years ago
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.
(Assignee)

Comment 10

5 years ago
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/
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.
Keywords: qawanted
(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.
I'm not QA, but I didn't see the issue. I only tried with a single profile, however.
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.
Keywords: qawanted
(Assignee)

Comment 15

5 years ago
I dare say we are fixed here then. Thanks for the QA.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
status-firefox11: --- → fixed
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.