Closed Bug 770669 Opened 7 years ago Closed 2 years ago

Update from classic to bootstrapped extension doesn't update metadata, the extension is treated as a classic extension

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gaubugzilla, Unassigned)

References

Details

A first bootstrapped Adblock Plus release came out last Thursday. However, judging by user reports the new version was completely broken for a not insignificant percentage of our users. The update from the classic extension (Adblock Plus 2.0.3) to a bootstrapped extension (Adblock Plus 2.1) failed somehow. What I managed to find out:

* Add-ons Manager preferences look as if the update didn't happen. extensions.bootstrappedAddons is "{}", extensions.enabledAddons includes "{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3". Consequently, Add-ons Manager continues treating Adblock Plus as a classic extension which completely breaks it - the extension looks enabled but only its chrome:// namespace is actually working. I managed to reproduce the symptoms in my test profile by changing these preferences in the same way.
* The extension has been updated successfully however and extensions.sqlite correctly lists is as bootstrapped. In fact, disabling it in Add-ons Manager doesn't suggest that a restart is required.
* Disabling and re-enabling seems to fix the issue even though this apparently doesn't work every time - for whatever reason.

So far I was unable to figure out how things ended up in this bad state. This appears to affect users across all operating systems, the only reported Firefox version is 13.0.1 however (doesn't have to mean anything of course, that the one most people use).
I found one possible way of getting into this state:

1. Install Adblock Plus 2.0.3 from https://addons.mozilla.org/addon/adblock-plus/versions/2.0.3/, restart browser.
2. Press Ctrl-Shift-A to open the Add-ons Manager, right-click Adblock Plus entry and choose Find Updates. Restart browser again after the update installs. Note that Adblock Plus works.
3. Force prefs.js to be written, e.g. by going to about:config and changing some value.
4. Kill the Firefox process and start it again.

After going through these steps Adblock Plus will no longer be functional - no toolbar icon, Ctrl-Shift-F doesn't do anything, ads aren't blocked.
The following code in XPIProvider.jsm is supposed to guard against this situation:

>      if (extensionListChanged || hasPendingChanges) {
>        LOG("Updating database with changes to installed add-ons");
>        XPIDatabase.updateActiveAddons();
>        XPIDatabase.commitTransaction();
>        XPIDatabase.writeAddonsList();
>        Services.prefs.setBoolPref(PREF_PENDING_OPERATIONS, false);
>        Services.prefs.setCharPref(PREF_BOOTSTRAP_ADDONS,
>                                   JSON.stringify(this.bootstrappedAddons));
>        return true;
>      }

This makes sure that the bootstrappedAddons pref gets updated immediately on startup rather than on browser shutdown. However, this code doesn't run in this scenario - the extension list didn't change (an add-on was merely updated by a newer version of itself) and there are no pending operations (a bootstrapped extension can be initialized immediately).

I reproduced this issue in the 16.0a1 (2012-07-03) nightly so this isn't limited to the 13 branch.
Version: 13 Branch → Trunk
Hm, I can't reproduce given the steps in comment 1.

(In reply to Wladimir Palant from comment #1)
> 2. Press Ctrl-Shift-A to open the Add-ons Manager, right-click Adblock Plus
> entry and choose Find Updates. Restart browser again after the update
> installs. Note that Adblock Plus works.

At this point, the old addon is completely gone and all that remains is the new addon. If the steps after this are the cause, then I'm not sure how the non-restartless -> restartless upgrade would be related.

> 4. Kill the Firefox process and start it again.

This step seems very fishy.
(In reply to Wladimir Palant from comment #2)
> The following code in XPIProvider.jsm is supposed to guard against this
> situation:
> 
> >      if (extensionListChanged || hasPendingChanges) {
> >        LOG("Updating database with changes to installed add-ons");
> >        XPIDatabase.updateActiveAddons();
> >        XPIDatabase.commitTransaction();
> >        XPIDatabase.writeAddonsList();
> >        Services.prefs.setBoolPref(PREF_PENDING_OPERATIONS, false);
> >        Services.prefs.setCharPref(PREF_BOOTSTRAP_ADDONS,
> >                                   JSON.stringify(this.bootstrappedAddons));
> >        return true;
> >      }
> 
> This makes sure that the bootstrappedAddons pref gets updated immediately on
> startup rather than on browser shutdown. However, this code doesn't run in
> this scenario - the extension list didn't change (an add-on was merely
> updated by a newer version of itself) and there are no pending operations (a
> bootstrapped extension can be initialized immediately).

That runs on the first startup after the upgrade (ie, step 2), where there was a pending operation (since the old version was non-restartless). Given that the restartless addon is working at this point indicates that code seems to be working as intended.

On the second startup, there shouldn't be anything to do.
Hmm.... unless... step 3 is wrong, and the process is:

1. upgrade
2. restart
3. kill process
4. startup


Which I think would mean the new value for extensions.bootstrappedAddons might not be guaranteed to have be written to disk. Though, if that's the case, I wouldn't expect the chrome to be registered (for non-restartless addons, chrome is loaded based on extensions.ini which is written to disk earlier - extensions.enabledAddons is only used for the crash reporter). But it would show the addon as being enabled in about:addons.
(In reply to Blair McBride (:Unfocused) from comment #4)
> That runs on the first startup after the upgrade (ie, step 2), where there
> was a pending operation (since the old version was non-restartless). Given
> that the restartless addon is working at this point indicates that code
> seems to be working as intended.

After updating the extension and restarting (step 2) I see this log message with logging enabled (after the messages indicating install method in bootstrap.js being called):

> LOG addons.xpi: No changes found

This clearly indicates that there is no pending operation at this point - at least in a clean profile with Adblock Plus as the only extension (I wasn't able to reproduce in my usual test profile for some reason). And while the extension is working, extensions.bootstrappedAddons pref hasn't been updated at this point. That pref would normally still be updated on shutdown but killing the browser in step 4 prevents that.

> Though, if that's the
> case, I wouldn't expect the chrome to be registered (for non-restartless
> addons, chrome is loaded based on extensions.ini which is written to disk
> earlier

The extensions.ini file still has an Adblock Plus entry in my test profile after performing the steps in comment 1, the broken profile of a user that I looked at had it as well.
I just checked - even if I omit step 4 and just restart the browser normally, extensions.ini doesn't change and still has an entry for Adblock Plus. Looking at my regular profile, this should normally not be the case. This entry is only removed when I disable and re-enable the extension, not before shutdown however. It doesn't break anything but it doesn't seem right either.
bootstrapped extensions are no longer supported
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.