If the application crashes before shutting down after a change to the disabled state of an add-on then the add-on gets stuck in needs restart

NEW
Unassigned

Status

()

Toolkit
Add-ons Manager
7 years ago
2 years ago

People

(Reporter: myk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 515744 [details]
extensions.sqlite from stuck profile

Wanting to see if Flashblock was causing problems on a Flash-heavy site I visited, I tried to disable it by opening the Add-ons Manager, pressing its Disable button, and then clicking the "Restart now" link that appeared.

My browser window disappeared, but it didn't reappear, so I checked, and the firefox-bin process was still alive.  So I killed it with "killall firefox-bin" and then started Firefox manually.

Whereupon I found Flashblock still in the "Flashblock will be disabled after you restart Minefield" state.  Clicking "Restart now" again caused Firefox to restart successfully this time, but it didn't change the state: Flashblock is still enabled, and Firefox still wants me to restart to disable it.

I tried to reproduce on a vanilla profile but was unable to do so.  I will attach extensions.sqlite and extensions.log in case they help track down the cause of the problem.

Note: I am using the latest Minefield nightly build.
(Reporter)

Comment 1

7 years ago
Created attachment 515746 [details]
extensions.log from stuck profile
Is the value of extensions.pendingOperations false?
(Reporter)

Comment 3

7 years ago
(In reply to comment #2)
> Is the value of extensions.pendingOperations false?

Yes, it is false.
This will probably fix itself if you either set extensions.pendingOperations to true or make a change to any other add-on, either disabling or removing etc.

The problem is that we make changes to the database on shutdown to finally change an add-on from pending-disable to disabled. If you crash before that then those changes don't happen. We also set a flag in preferences to say that a change is necessary but if you crash before prefs are written to disk then that is lost too.

There are two ways to solve this. One is to force the prefs to flush to disk when we set the flag, but we don't have an async way to do that so sdwilsh and mobile would be angry at me. The other is to have some code that verifies the DB consistency the next time it is loaded and I'm not entirely sure where this would go right now.

The fact that this goes away on any other add-ons change (I presume you can even undo the disabling and click disable again and it'll probably work) means this isn't too serious though.
Summary: Add-ons Manager stuck in addon "will be disabled after you restart" state → If the application crashes before shutting down after a change to the disabled state of an add-on then the add-on gets stuck in needs restart
(Reporter)

Comment 5

7 years ago
(In reply to comment #4)
> The fact that this goes away on any other add-ons change (I presume you can
> even undo the disabling and click disable again and it'll probably work) means
> this isn't too serious though.

Yup, that worked!  So it sounds like your diagnosis is correct and the workaround is fairly simple (albeit obscure).
Duplicate of this bug: 1096017
You need to log in before you can comment on or make changes to this bug.