Steps to reproduce: - Load a temporary WebExtension without ID in about:debugging - Add an ID to its manifest - Reload the extension Expected results: The previous ID-less version gets replaced by the new version with ID. Actual results: The previous version doesn't get removed and now the extension is loaded twice, however the first instance is no longer listed. This is potentially a bug within addon.reload() from the Add-ons Manager.
Thank you Martin for reporting this bug! (In reply to Martin Giger [:freaktechnik] from comment #0) > This is potentially a bug within addon.reload() from the Add-ons Manager. Kumar, could you please have a look to see if that's the case?
Priority: -- → P2
> The previous version doesn't get removed and now the extension is loaded twice, > however the first instance is no longer listed. To clarify, what I see is this (in Nightly): - about:debugging does not list the old add-on, it only lists the new one (this behaves as expected) - about:addons lists both the old and new add-on (this is unexpected) Regardless of what the UI shows, logging tells me that the old add-on (which has a different ID) is not getting removed. This does sound like a bug in reload(), specifically in that it is passing addon._sourceBundle (the add-on directory) to installTemporaryAddon() but is not passing in the old add-on ID https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#7512 The installTemporaryAddon() function is the one responsible for removing the old add-on but in this case it does not check for any running add-ons having the old ID. It seems like a bit of an obscure edge case to be changing the add-on ID during development though. I don't think it would be so hard to workaround (as a developer) so I'm not sure if it's a P2.
You need to log in before you can comment on or make changes to this bug.