260152 - Extensions show as compatible with 1.0PR but when downloaded are not

Status: RESOLVED WORKSFORME

(Toolkit :: Add-ons Manager, defect)

Description

[Tom Hanna]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.8 StumbleUpon/1.994
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.8 StumbleUpon/1.994

Several of the extensions listed as being compatible with Firefox 1.0PR release
return an error message when installed that they are not compatible with the
release.

Reproducible: Always
Steps to Reproduce:
1. Browse Firefox extensions
2. Set version equal to Firefox 1.0PR
3. Click "update"
4. Select install on any of the following:
   IE View 0.81
   QuickNote 0.5.9.2
   

Actual Results:  
A message popped up indicating the extension was not compatible with Firefox
1.0PR even though the webpage indicated that it was.

Expected Results:  
Installed correctly or not been listed as compatible with the build?

Comment 1

[alanjstr]

Sounds like the EM isn't checking UMO during install.

Comment 2

[Wolf [:wolf]]

humm.. quicknote has a externally facing update.rdf.. and its install.rdf only
has compatibility to 0.9.1+, even though the update DB was modified to show its
support for 0.10 as we're supposed to be able to do. Perhaps Firefox does /not/
check UMO for externally facing update.rdf's? (the update.rdf in quicknote has
no version info or anything in it.)

IEView, OTOH, had the wrong guid in the update DB.. (the initial version added
appears to be a repackage and not official, but that was 0.7 and is no longer in
the DB) so firefox was failling to be able to query for it successfully and
falling back to install.rdf.

Comment 3

[alanjstr]

AFAIK, it doesn't recognize that the DB for Pinball has been updated, unless I
did it wrong.  It says its ok to download, but fails during the install.

Comment 4

[Nickolay_Ponomarev]

imo, forcing the online check is cruel to dial-up users. The XPIs on u.m.o that
are listed as compatible should have correct install.rdf (force extension
authors to submit new XPIs or repackage them automatically (which will cause
problems with signing)).

Comment 5

[alanjstr]

The update webservice doesn't use a lot of bandwidth.  The point of allowing
update.rdf to override the install.rdf is so that an author does NOT have to
repackage every time there is a new release.  With the rapid development cycle
of Firefox, they'd be spending all their time changing install.rdf instead of
making their products better.  The installer could at least prompt you to check.

Comment 6

[Nickolay_Ponomarev]

I understand that. My point was: in order to install a /downloaded/ extension
one has to establish an Internet connection.

Imagine a person who is used to downloading everything before installing (in
order to avoid redownloading later). He right-clicks on the u.m.o link (that
says right-click to download), downloads the XPI and goes offline. Then he tries
to install the (compatible) extension and gets a message it is incompatible and
that firefox needs an internet connection to check if any updates are available.
This, along with absence of UI for turning the version check off (something like
Install Anyway) doesn't sound sane at all to me. My opinion is that u.m.o should
provide correct XPIs for download (though I understand that it's not easy to
implement).

Back on topic. If this bug is real (which means firefox really doesn't check
u.m.o/em:updateURL for compatibility updates), it should be confirmed and fixed
before 1.0 - as it means that users can't install the extensions with bumped
maxversion, and that defeats the purpose of using update.rdf for bumping. 

Alan, Wolf could you set up a test extension with different maxversions in
install.rdf and DB?

Comment 7

[alanjstr]

I had diff versions for Pinball 0.9.9.  Install.rdf says maxVer is 0.10+.
update.rdf should say 1.0.  FX Update tells me there is an update available, so
I download it. But then it won't install because install.rdf says maxVer is
0.10+ and not 1.0

Comment 8

[Wolf [:wolf]]

(In reply to comment #3)
> AFAIK, it doesn't recognize that the DB for Pinball has been updated, unless I
> did it wrong.  It says its ok to download, but fails during the install.

I've fixed those records, you definitely confused the website. :-) by flipping
the Min/Max Ver internal values and not changing the MinAppVer/MaxAppVer values.
(Which is what the webservice uses)

Comment 9

[Nickolay_Ponomarev]

We noticed that QuickNote's update.rdf's maxver bumps are not read by Firefox's
update checker, probably because update.rdf is sent as text/xml instead of
text/rdf. So both items had problems of their own; it's not a EM bug [unless
someone can prove opposite]. Should it be closed?

(bug 275911 sounds like a dupe - is is about Image Zoom and All-in-One Gestures.)

Comment 10

[alanjstr]

Well, why isn't EM able to cope with the wrong MIMEtype?  Or is the update.rdf
just invalid

Comment 11

[Nickolay_Ponomarev]

oops. Just re-tested with Thunderbird 1.0, and it works correctly.

I can swear it didn't work last time I tried (in TB 0.8, and we even got a bug
report about it). I must have made a mistake that time.

Anyways, this report is WFM. I just tried to install QuickNote 0.6 which has
0.6-0.8+ Thunderbird compatibility in Thunderbird 1.0, clean profile and it
installed correctly. When it doesn't work, it means either a mistake on
update-db maintainer part or that Firefox couldn't connect to internet to check
if there were any version bumps. (It would be nice if corresponding text was
included in the error box, but that's a different issue).