1007732 - mapURIToAddonID fails for bootstrapped add-ons detected at startup

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

For some reason the fixes in bug 986755 don't work for the cfx run case

Comment 1

[Dave Townsend [:mossop]]

Bug causes us to throw away URI mappings for bootstrapped add-ons detected at startup

Comment 2

[Dave Townsend [:mossop]]

Attachment: patch

The way we build up locations for mapURIToAddonID is sort of crazy, parsing through the installcache pref and other bits to get stuff. It also gets wiped out during startup after some of the mappings have been set when a new restartless add-on is detected.

I think it's much saner to do it as part of the install location scan. We already have direct access to all the add-on's locations there so it's trivial to record them.

This has a side effect. We can now map all disabled add-ons. Previously we could only map disabled add-ons if they had been previously enabled. I don't think this is a bad thing but if we still need the old behaviour then I think there are easier ways to get there than the way the current system works.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 8420201 [details] [diff] [review]
patch

Review of attachment 8420201 [details] [diff] [review]:
-----------------------------------------------------------------

Oh, huh - that's much more elegant!

Comment 4

[Dave Townsend [:mossop]]

https://hg.mozilla.org/integration/fx-team/rev/837eed8de5c1

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/837eed8de5c1

Comment 6

[Dave Townsend [:mossop]]

This potentially breaks the add-on debugger and about:memory for add-ons detected at startup. I don't think that's enough of a problem to want to press on with an uplift but could be argued otherwise.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

No activity for a month on this bug and no uplift request after the aurora cycle. I guess we don't want an uplift here.