378385 - Checking for Add-ons updates fails.

Status: RESOLVED INCOMPLETE

(Toolkit :: Add-ons Manager, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070420 Firefox/3.0a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070420 Firefox/3.0a4pre

Checking for updates in pre-releases fails.


Reproducible: Always

Steps to Reproduce:
1. Compile a recent CVS release, e.g. Firefox 3.0a4pre.
2. Run it and try Tools -> Add-ons and select [Find Updates]
Actual Results:  
Many extensions report:
"An error occurred while trying to find updates for XXZZY", where XYZZY may be Cache Status, Greasemonkey, NoScript, etc. (probably most extensions).

However, "DOM Inspector 1.9a4pre" reports "No updates were found".

Expected Results:  
If the "DOM Inspector" is check is successful, then the others should be as well.
If Firefox 3.0a4pre isn't a valid "version", then one should allow 3.0a3 or 3.0 version matching.

In any case, when one has: user_pref("extensions.checkCompatibility", false)
set in prefs.js there should be no version checking during "Find Updates" requests.

If someone reads this report who really understands how version checking for extension updates works, please cite the precise source files involved to deal with this bug report.

I've tried looking into this and there appears to be some complex interaction between min & max versions in the extension install.rdf files and the settings in the prefs.js file.  However I strongly suspect that this is unrelated to "An error occurred" error messages because that is different from what one gets when there are version incompatibilities.

Comment 1

[Robert Bradbury]

As it turns out, at least two files must be changed to alter the Firefox/Mozilla version strings, they are:
  browser/config/version.txt
and
  config/milestone.txt

Question 1: Is this documented anywhere?  Or is one to doubt the comments in 
  config/milestone.txt:

# Hopefully I'll be able to automate replacement of *all*
# hardcoded milestones in the tree from these two files.

If the "two files" are milestone.txt and milestone.pl, then obviously that "goal" has not happened given the requirement for browser/config/version.txt.
And this is what the 3rd "production" release???

Changing these files to modify 3.0a4pre/1.9a4pre to 3.0a3 and 1.9a3 does *not* fix add-on update checking or version recognition.

The Firefox CVS version is from 19 April 2007.  The versions tested include 3.0a4pre and 3.0a3 (by changing the version strings in the files documented above and recompiling the the source.  (Based on some assumptions that source strings containing "pre" or "a4" may not produce valid extension version recognition queries.)

Using the Tools -> Add-ons -> [Find Updates] results in most updates giving the

"An error occurred while trying to find updates for ..." error.

That is *not* a tremendously informative error message!

Examining the NoScript extension says "Not compatibile with Firefox 3.0a3" in spite of the fact that the NoScript extension page says it is compatible up through a4!

It is worth noting that altering prefs.js to use:
  user_pref("extensions.checkCompatibility", false);
will allow the existing installed versions of Greasemonkey (0.6.6.20061017.0) and NoScript (1.1.4.5.061221) to run properly, attempts to install updated extensions, e.g. NoScript 1.1.4.8.070423 (at least using the "Find Updates" feature) fails.

Precisely what files/code must be changed in Firefox and/or the external JS/JAR/Extension packages to allow update checking to work with versions compiled from the CVS system?

If you are trying to encourage people to work on extensions or debugging extensions you have created a catch-22 situation.  One shouldn't file bug reports unless one is using the current CVS souces.  One can't install extension updates with the current CVS sources.  There is no (apparent) documentation on how to reconcile Firefox and extension version numbering systems to allow one to assemble the most recent CVS + extension sources simultaneously.

Comment 2

[Dave Townsend [:mossop]]

DOM inspector is not checked for updates since it is shipped with the product. Nightly builds (which are compiled direct from CVS) seem to check for updates just fine so I suspect an issue with your particular build. Can you enable the pref extensions.logging.enabled, then do an update check for just one extension and then report the messages logged to the error console.

Comment 3

[Dave Townsend [:mossop]]

Please reopen this if you can provide the requested information.