Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050424 Firefox/1.0+ repro: 1. just wait for the update icon to appear + message updates available 2. check the versions, none of them are actually updates I assume this is fallout from Bug 286034

I just veriefied with the owner of JSOptions 1.0 ( http://www.blueprintit.co.uk/~dave/web/firefox/jsoptions/index.html ) He confirmed he hasn't made a change to the extension in the past month

Confirming Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050424 Firefox/1.0+

It appears that the update service is sending the string &version=app-profile to UMO though UMO isn't providing update info with this invalid data being sent. So, extensions that use the update info provided by UMO and extensions without an updateURL defined in their install.rdf are not shown as needing an update. Extensions that have a valid updateURL defined in their install.rdf are being shown as needing an update and I suspect this is also due to the string app-profile being used for version.

In my case all 3 extensions that pretend to require an update are non-UMO.

(In reply to comment #3) > It appears that the update service is sending the string &version=app-profile to > UMO though UMO isn't providing update info with this invalid data being sent. Good point. This problem is occured by items which use custom RDF file, so UMO server is not related. This is caused by a simple typo. makeItem() function is refered from 3 points, but one is wrong argument order.

I checked this in with fixes to 291831.