Closed Bug 619607 Opened 9 years ago Closed 9 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla2.0b10
Tracking Status
blocking2.0 --- final+

People

(Reporter: Mardak, Assigned: mossop)

Details

Attachments

(1 file, 1 obsolete file)

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:

http://hg.mozilla.org/mozilla-central/annotate/e952221c3251/toolkit/mozapps/extensions/XPIProvider.jsm#l2882

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).
We should attempt to recover in the event of a bad pref here.
blocking2.0: --- → final+
Assignee: nobody → dtownsend
Whiteboard: [waiting on try]
Attached patch patch rev 1 (obsolete) — Splinter Review
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)
Whiteboard: [waiting on try] → [has patch][needs review rs]
Attached patch patch rev 1Splinter Review
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+
Whiteboard: [has patch][needs review rs] → [has patch]
Landed: http://hg.mozilla.org/mozilla-central/rev/3df7a7d16992
Status: NEW → RESOLVED
Closed: 9 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.
Status: RESOLVED → VERIFIED
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.