650216 - Users can end up running files from different versions of the same extension

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Wladimir Palant]

This is based on an end-user bug report (https://adblockplus.org/forum/viewtopic.php?p=44912#p44912). His Adblock Plus installation reported itself as being Adblock Plus 1.3.3 (meaning that Utils.jsm was from Adblock Plus 1.3.3). Further errors indicate that all JavaScript modules were from Adblock Plus 1.3.3 while UI code used (meaning adblockplus.jar) was from Adblock Plus 1.3.5 (AppIntegration.jsm trying to access a UI element that was removed in the newer Adblock Plus version, UI scripts trying to access a JS module method that was only introduced in Adblock Plus 1.3.5).

I don't really have an idea how the user got into this state. He was running Ubuntu Linux 64bit and Firefox 4.0 from firefox-stable ppa. He probably upgraded from Firefox 3.6 recently but his profile only contained the expected XPI file for Adblock Plus, no directory with the unpacked extension. According to the user removing that XPI didn't help, reinstalling Firefox did fix the issue however. I can only suspect that he originally installed Adblock Plus 1.3.3 globally (from the Linux repository) and then got an update via AMO that got installed into his profile. Which still doesn't explain how both add-ons ended up being used simultaneously.

It might be relevant that Adblock Plus loads both modules and UI code from chrome:// namespaces (for the further chrome://adblockplus-modules/, for the latter chrome://adblockplus/).

Comment 1

[Tony Mechelynck [:tonymec]]

In reply to comment #0:
Instead of reinstalling Firefox, have your user uninstall Adblock Plus, restart Firefox, repeat until there is no "Adblock Plus" entry in the add-ons manager, then reinstall Adblock Plus (into his profile). This should make sure that only one copy is present. This would probably make all symptoms disappear for this user, but it is not a fix, only a workaround (the underlying bug could yet bite another user).

What you're saying implies that your user did check for both a {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} folder and a {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi in <profiledir>/extensions (and found only the latter), but maybe there was one or the other left in <appdir>/extensions; the procedure in my first paragraph above would make sure that we start with a clean slate.

Comment 2

[Wladimir Palant]

It's too late to give this user an advise - he already solved his problem. And uninstalling globally installed extensions won't be possible from the browser anyway (permissions). I *guess* that when he uninstalled Firefox dependent packages (including Adblock Plus 1.3.3) were uninstalled as well, when he reinstalled then they weren't installed again.

Comment 3

[Dave Townsend [:mossop]]

Thanks for the report though I'm not sure how far we'll be able to get without more data at this point. A few random thoughts:

Since both modules and UI are loaded from chrome: that likely rules out any issues with multiple copies of the extension appearing in extensions.ini (even if they were there the chrome registry can't register the same namespace to multiple directories).

Modules and UI are cached in different ways, even when loaded from chrome: so that is a pretty attractive prospect for being the source of this bug. We are meant to be invalidating both XUL and startup caches (since bug 606076) but maybe there is some case where we aren't. Bug 592943 which is hopefully coming would ensure that we can never have that problem.

If this happens in the future gathering a few files from the user would at least help confirm/deny this:

XUL.mfasl and startupCache/startupCache.8.little from the local profile
extensions.sqlite and extensions.ini from the main profile

Comment 4

[Wladimir Palant]

(In reply to comment #3)
> Since both modules and UI are loaded from chrome: that likely rules out any
> issues with multiple copies of the extension appearing in extensions.ini (even
> if they were there the chrome registry can't register the same namespace to
> multiple directories).

They are different namespaces - one is inside a JAR file, the other needs to be outside for Firefox 3.6 compatibility.

Comment 5

[Dave Townsend [:mossop]]

(In reply to comment #4)
> (In reply to comment #3)
> > Since both modules and UI are loaded from chrome: that likely rules out any
> > issues with multiple copies of the extension appearing in extensions.ini (even
> > if they were there the chrome registry can't register the same namespace to
> > multiple directories).
> 
> They are different namespaces - one is inside a JAR file, the other needs to be
> outside for Firefox 3.6 compatibility.

Ah well that re-opens that possibility then I guess, though I'd find it odd that one mapping pointed to one and the other to another, unless the namespaces happened to change name between the versions at all?

I think my money is still on a caching problem at the moment.

Comment 6

[Wladimir Palant]

No, the namespaces didn't change, they were the same in both versions. Caching could be the issue of course but I find it strange that the caches weren't cleared despite extension reinstallation (at least I guess that there was one).

Comment 7

[Dave Townsend [:mossop]]

(In reply to comment #6)
> No, the namespaces didn't change, they were the same in both versions. Caching
> could be the issue of course but I find it strange that the caches weren't
> cleared despite extension reinstallation (at least I guess that there was one).

Yeah, I can't really think of a scenario that is less strange at this point though. It may just be a red herring that the two things that are different are in different caches but there isn't a lot else to go on right now.

Comment 8

[Ben Bucksch (:BenB)]

Wladimir, is AdBlock Plus maybe packaged as deb (Debian/Ubuntu package)?

> We are meant to be invalidating both XUL and startup caches

That's what the extension installer in Firefox does, yes. Nothing else in Firefox does that, right?

Maybe the deb installer didn't clear the startupCache or mozJSComponentLoader's cache (compare bug 649029 comment 5).

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.