314258 - ExtensionItemUpdater:checkForDone: Failure in listener's onAddonUpdateEnded

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Daniel Veditz [:dveditz]]

When testing autoupdate from Thunderbird 1.5beta2 to 1.5rc1 I got exceptions on the javascript console:

nsIAddonUpdateCheckListener is not defined
Source File: file:///C:/Program%20Files/Mozilla%20Thunderbird%201.5/components/nsUpdateService.js
Line: 2706

ExtensionItemUpdater:checkForDone: Failure in listener's onAddonUpdateEnded: [Exception... "'[JavaScript Error: "nsIAddonUpdateCheckListener is not defined" {file: "file:///C:/Program%20Files/Mozilla%20Thunderbird%201.5/components/nsUpdateService.js" line: 2706}]' when calling method: [nsIAddonUpdateCheckListener::onAddonUpdateEnded]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Thunderbird%201.5/components/nsExtensionManager.js :: anonymous :: line 5006"  data: yes]

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: supply missing object reference

Comment 2

[Darin Fisher]

Ben said the following over IM:

  "it seems that you'll always get a prompt regardless of whether or not extension updates are available that would make the update compatible with all your extensions... that's broken"

So, the downside to not taking this patch is extra prompting.

Comment 3

[Darin Fisher]

Comment on attachment 201204 [details] [diff] [review]
supply missing object reference

Looking for rc2 approval / consideration.

Comment 4

[Asa Dotzler [:asa]]

moving out to the 1.8 rc2 ride-along candidate list. We'll consider taking this if we do an RC2.

This needs to be landed on the trunk to verify that this works. 

Comment 5

[Daniel Veditz [:dveditz]]

landed on the trunk

Comment 6

[Dave Liebreich [:davel]]

I'm running into a bit of a snag in testing this patch.  I need an extension that is compatible with the current version but none greater, an update that identifies itself as a greater version, and a newer version of that extension that is compatible with the new version.

I can try this by faking the responses from aus and umo.  Is there an easier way?

BTW, the extension mentioned by dveditz as triggering this bug does not have an update on umo.  Does it use a custom updateURL in install.rdf?

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> BTW, the extension mentioned by dveditz as triggering this bug does not have an
> update on umo.  Does it use a custom updateURL in install.rdf?

Yes it does. Enigmail (now OpenPGP) has binary components that link to unsafe APIs, so the 1.0x-compatible version on AMO won't work with 1.5. I've gotten a 1.5-compatible version from http://enigmail.mozdev.org

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> I need an extension that is compatible with the current version but none
> greater,

That was easier to find a week or two ago. You can grovel through ftp://ftp.mozilla.org/pub/mozilla.org/extensions and narrow your search to extensions that haven't been updated in a while. Or ask on #umo-dev and get one of the admins (e.g. morgamic) to search the db for you.

> an update that identifies itself as a greater version, and a newer
> version of that extension that is compatible with the new version.

once you find a compatible extension you could install an older version of it. I don't think you can get old versions from the AMO interface, but you can get them off the ftp site.

I hope you're testing in Firefox. The code is shared and if you're restricting yourself to Thunderbird extensions you won't have very many choices.

Another testing note: nsUpdateService.js is a raw js component. If it helps testing at all you can hand-patch the file in your 1.4.1/1.5 build.

Comment 9

[Dave Liebreich [:davel]]

tested on MacOS X
manual and automatic update
compat update present for extension and new ext version
builds before and after patch (20051031 and 20051101)

Patch does not change user-visible behavior

all manual tests prompted user for go-ahead, stating that extension will be disabled until it is updated.

for compat update (extension update has same version, bumped up max app vers), auto updated completed without usre intervention

for ext update (new version in ext update), auto update required user approval in all cases.

javascript console error messsage was only present for 20051031 build for auto-update when updateURL is specified in install.rdf.  error messages were not present when using extensions.update.url.

suggest we open a new bug if user-visible behaviour needs to be changed.

I will test on windows and linux today

Comment 10

[Dave Liebreich [:davel]]

I did not test on Windows and Linux today, but I attached a test case (with support files) to bug 302059.  The patch on the trunk did fix the js console error messages, but did not produce the desired behavior.

Comment 11

[Mike Schroepfer]

DVeditz Should we land this on the branch or no?

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

At the risk of this being bugspam, I figured we should get the following on record. From a user experience and product perspective, the "bad thing" is a case where a user is dissuaded from updating for fear that they will have extensions that will be rendered inoperative when, in fact, that would not be the case.

Comment 10 seems to imply that this isn't fixed, which makes me wonder why the bug is marked resolved fixed.

Comment 13

[Scott MacGregor]

do we still intend to land this patch on the branch tonight?

Comment 14

[Darin Fisher]

fixed1.8