Incorrect extensions.bootstrappedAddons prevents other bootstrapped add-ons from loading

VERIFIED FIXED in mozilla2.0b10



Add-ons Manager
7 years ago
6 years ago


(Reporter: Mardak, Assigned: mossop)


Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)



(1 attachment, 1 obsolete attachment)



7 years ago
Not quite sure how I got in the state, and I've cleaned it up without a backup of the bad state...

But I opened my Firefox 4 profile in Firefox 3.6 and canceled the dialog that asked if I wanted to install a list of add-ons that were found. After returning to Firefox 4, various things broke even after I reinstalled the add-ons.

It seems like extensions.bootstrappedAddons had references to the add-ons that no longer existed in my profile and XPIProvider was throwing:

The call to isDirectory() was failing because it didn't exist. And I assume its caller also broke and didn't continue to the rest of the bootstrapped add-ons.

So I reset extensions.bootstrappedAddons pref and restarted and things seemed okay (after I nuked {addons,extensions}* in my profile directory).

Comment 1

7 years ago
We should attempt to recover in the event of a bad pref here.
blocking2.0: --- → final+


7 years ago
Assignee: nobody → dtownsend


7 years ago
Whiteboard: [waiting on try]

Comment 2

7 years ago
Created attachment 502533 [details] [diff] [review]
patch rev 1

This patch makes it so whenever we run through the full list of extensions at startup (normally if the database needs to be rebuilt or an extension has been installed/uninstalled or a change to the extensions in the install locations has been made) then the bootstrappedAddons object is completely rebuilt. This means any errors in that list will be fixed the next time the app updates or an extension change occurs. Some additional code also verifies that all the add-ons listed in bootstrappedAddons actually exist on disk, if any don't then we force a rebuild too. The test verifies that starting with an invalid directory in that list is detected and repaired.

With this patch I think the worst case we could get into would be if bootstrappedAddons didn't contain an add-on it was meant to, this is the safest way to fail I think and without bringing up the DB we can't automatically correct this on startup.
Attachment #502533 - Flags: review?(robert.bugzilla)


7 years ago
Whiteboard: [waiting on try] → [has patch][needs review rs]

Comment 3

7 years ago
Created attachment 502600 [details] [diff] [review]
patch rev 1

The right patch this time.
Attachment #502533 - Attachment is obsolete: true
Attachment #502600 - Flags: review?(robert.bugzilla)
Attachment #502533 - Flags: review?(robert.bugzilla)
Attachment #502600 - Flags: review?(robert.bugzilla) → review+


7 years ago
Whiteboard: [has patch][needs review rs] → [has patch]

Comment 4

7 years ago
Last Resolved: 7 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla2.0b10
Marking as verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre

I have used the vague steps from comment 0 with the additional info from following comments, but wasn't able to reproduce any breakage now. The bootstrappedAddons pref gets correctly reset, once listed extensions don't exist anymore.
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.