666492 - SM upgrade leaves built-in extensions like ChatZilla disabled

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[skierpage]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: 2.2b1

When I updated SeaMonkey 2.0.14 to 2.2b1 in Windows Vista, SeaMonkey reported ChatZilla 0.9.87 was incompatible and disabled it!  Someone else mentioned the glitch in http://forums.mozillazine.org/viewtopic.php?f=6&t=2013041 (but I don't think filed a bug), and others in IRC #seamonkey are having the problem.

It may be triggered by having an earlier CZ in your profile that's received updates separately from SeaMonkey; I think at one point in 2.0.x I installed the CZ .xpi from addons.mozilla.org to work around a bug.

Reproducible: Sometimes

Steps to Reproduce:
Not sure, something like:
1. Upgrade to SeaMonkey 2.2b1
2. Start with your old profile


Actual Results:  
The extension compatibility check on first run warned the following addons are incompatible: ChatZilla 0.9.87, I clicked to find an update and it reported (roughly) No Compatible Add-on versions Found. Then about:addons > Extensions reports
  ChatZilla is incompatible with SeaMonkey 2.2
  ChatZilla 0.9.87 (disabled)

But this is the same version reported working in a clean profile!

So I removed this ChatZilla and restarted, now CZ was gone altogether.  Then the great KaiRo suggested "go to about:config, and reset extensions.lastAppVersion and restart SeaMonkey".  Those two steps together worked, I had a working CZ, yet with an unchanged version number.

Expected Results:  
I'm not sure, but
1. The "No Compatible Add-on versions Found" message is misleading as CZ comes with SeaMonkey!
2. If the built-in ChatZilla in SM 2.2b1 had a different version number -- "0.9.87(built-in)" -- than a previous CZ from 2.0.x, it would help to make sense of what's going on.

The install.rdf for the current CZ on addons.mozilla.org still says <em:maxVersion>2.1.*</em:maxVersion> yet it has the same <em:version> as the built-in!  That's clearly wrong?

Comment 1

[skierpage]

It happens on Linux x64 too, and it happens with other extensions (so I changed the Summary).  I upgraded to seamonkey-2.2b1.en-US.linux-x86_64 and ran with an old existing profile, and it warned that Dom Inspector 2.0.10pre was incompatible, but it couldn't find a compatible update.

Comparing the [e-mail] in my old profile with the built-in version in seamonkey/distribution/extensions,
* the old one in profile is dated 2011-05-17, the built-in is dated 2010-01-01
* the em:version in install.rdf is identical "2.0.10pre", yet the two extensions have very different contents, including em:maxVersion.

I think this bug is serious and should block seamonkey-2.2 unless there's documentation for the problem with a reliable workaround.

Comment 2

[Tony Mechelynck [:tonymec]]

Does this bug belong in SeaMonkey::BuildConfig or in Toolkit::AddonsManager? Henrik, please check my reasoning.

Built-in extensions to SeaMonkey (ChatZilla, Venkman, DOM Inspector, and, in non-release builds, the Debug and QA UI) are now installed under <appdir>/distribution/extensions/ from where they ought to be copied to <profile>extensions when there is a general check for extensions' compatibility, i.e., after a version change, which is noticed at startup when the saved value of extensions.lastAppVersion is different from the current app version.

However, that copy doesn't happen if there is already a version of the same extension in the profile with (IIUC) an "equal or higher" version.

Since ChatZilla (Venkman, DOMi) version changes are not necessarily synchronous with SeaMonkey version changes, it may happen that the "dormant" builtin copy becomes "fresher" than the "active" copy in the profile, while keeping the same extension version number. In such a case the extension in the profile will not be updated, unless a clever user (a) uninstalls the profile copy or at least reduces the "extension version" in its install.rdf, and (b) triggers a version check, either by actually upgrading to a new app version, or at least making SeaMonkey believe than he did by restarting with a modified extensions.lastAppVersion setting.

Comment 3

[skierpage]

(In reply to comment #2)
Your last sentence sounds right, probably with a restart after a) and a restart after b).  For my disabled DOM Inspector I tried removing the disabled extension in about:addons and resetting extensions.lastAppVersion all at once, and then a single restart; that didn't work until I reset extensions.lastAppVersion a second time and restarted.

Is the build fix to bump up the em:versions of these extensions distributed with SeaMonkey 2.2?  That would trigger the copy and help users understand what's going on.

Comment 4

[skierpage]

I tried another old profile with SM 2.2b1, this said both ChatZilla and DOM Inspector disabled. This time the steps 1) remove both in about:addons, 2) restart, 3) reset extensions.lastAppVersion in about:config, and 4) second restart left both invisible in about:addons.  Guessing, I 5) reset extensions.installedDistroAddon.{59c81df5-4b7a-477b-912d-4e0fdf64e5f2} and [e-mail] (both were true) in about:config and reset extensions.lastAppVersion again, and 6) restarted a third time, and both were back in about:addons.

Comment 5

[Justin Wood (:Callek)]

Ok, this is a matter of getting additional things on our release-tracking list.

The update causes SeaMonkey to poke AMO for compat info if necessary, and if the compat info on AMO is not updated these get marked as incompatible regardless of what we ship with, it seems. (unless shipped-addon-ver is newer than profile addon)

I just got cZ updated on AMO, and DOMi will be soon. Also working on getting it so SeaMonkey can set this information on AMO ourselves.

Thank You for the investigation!

Comment 6

[rsx11m]

That's essentially the same as bug 580961, thus bumping the QAdebug extension as proposed by KaiRo would resolve the issue there as well for the time being. Whether or not bug 658283 would resolve the issue more elegantly by actually using the shipped up-to-date versions rather than poking AMO isn't clear to me.

Comment 7

[Tony Mechelynck [:tonymec]]

(In reply to comment #6)
> That's essentially the same as bug 580961, thus bumping the QAdebug
> extension as proposed by KaiRo would resolve the issue there as well for the
> time being. Whether or not bug 658283 would resolve the issue more elegantly
> by actually using the shipped up-to-date versions rather than poking AMO
> isn't clear to me.

Bug 658283 is for add-ons in the application directory. Nowadays, the only add-ons in SeaMonkey's application directory are the two themes. The built-in extensions are packaged in distribution/extensions (where they are inactive) to be installed in the profile... when the app gets around to it, which (currently) happens only on an app version change, and only if there is found to be no same- or later-version copy of the same extension already installed in the profile.