308522 - Extension check for update hang

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Robert Strong (they/them - no direct email)]

Brought to my attention by Ria - the following updateURL (from what appears to
be an abandoned extension) causes extension update to hang... it also takes what
seems a long time to timeout when opening the url as well.
http://xguru.xcool.net:1360/xpi/fastdic/update.rdf

Comment 1

[Robert Strong (they/them - no direct email)]

Need a bit of advice.

For this url the request never returns and the only way I can think of to deal
with this is to use a timer, track all of the requests, and abort any requests
that are still active after x amount of time. Ideas / comments are welcome...
Thanks.

Comment 2

[Robert Strong (they/them - no direct email)]

It turns out it does return but it often takes a long time to timeout... though
I didn't time it it seemed around two minutes. I'll attach an http log when I
have a chance.

Comment 3

[Keith Petersen]

For any abandoned Extensions/Themes the Mozilla Update site should change the update URL to an internal error handler page at their site that immediately answers with a non-fatal error message.  This would make the client's update manager continue on to the next extension to be checked.

Some examples of extensions that consistantly cause a long delay are:
Yahoo! Toolbar, xMirror, Wayback, Print It!, and Open Link Host.

Comment 4

[Robert Strong (they/them - no direct email)]

*** Bug 336775 has been marked as a duplicate of this bug. ***

Comment 5

[u88484]

Rob, sorry about the dupe. I waiting for about 45 minutes today and still no timeout. Also the wrong status for which extension was being checked was shown and relation or should I file a bug if not one open and what exactly is going on so that I don't summarize the problem wrong?

Comment 6

[Robert Strong (they/them - no direct email)]

If you read the message above the progress bar it state Finished checking for updates to etc. specifically due to the fact that we have never supported being able to state Checking for updates to etc. due to the requests being sent in parallel... so, the earlier version that stated we were checking for updates to were bogus and actually meant we had finished checking for updates to the extension.

Comment 7

[Mel Reyes]

Not specific to resolving the issue at hand, in the interim you can disable the update check for known abandoned extensions by setting the pref to false:

extensions.EXTENSIONTHEMEID.update.enabled 

where EXTENSIONTHEMEID is the id for the extension or theme.

Even easier, if you have my Local Install extension just right-click and select "Disable Update Check".

good luck.

Comment 10

[Gregor Larson]

I've been seeing these long delays/timeouts related to automatic updates on the bon-echo nightly build / update (winXP). The problem if more noticeable when you are doing updates every day :) . The problem can manifest itself during a manual check for updates or a automatic check. When it occurs, firefox is unresponsive for up to an hour (it almost always seems to recover if I wait long enough).

One angle I've been looking at is that it seems more likely to happen if firefox is 'busy', that is, when firefox has TCP streams established to remote servers (as seen in netstat or tcpview). I have changed my home-page to about: in order to try and isolate this better.

I will also try the above and/or removed some of my extensions (I use several).

------------ extensions.ini
[ExtensionDirs]
Extension0=W:\pcmoz\ff2\extensions\{F33233B3-EDB1-41f4-8482-917AB190E647}
Extension1=W:\pcmoz\ff2\extensions\{ba243cb0-b824-4a26-9418-73ee795d9b9d}
Extension2=C:\Program Files\Mozilla Firefox\extensions\[e-mail]
Extension3=W:\pcmoz\ff2\extensions\[e-mail]
Extension4=W:\pcmoz\ff2\extensions\[e-mail]
Extension5=W:\pcmoz\ff2\extensions\{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
Extension6=W:\pcmoz\ff2\extensions\{8620c15f-30dc-4dba-a131-7c5d20cf4a29}
Extension7=W:\pcmoz\ff2\extensions\{C0CB8BA3-6C1B-47e8-A6AB-1FAB889562D9}
Extension8=W:\pcmoz\ff2\extensions\{53A03D43-5363-4669-8190-99061B2DEBA5}
Extension9=C:\Program Files\Mozilla Firefox\extensions\[e-mail]
[ThemeDirs]
Extension0=C:\Program Files\Mozilla Firefox\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}

ps.
Is there a better way to get a text summary of extensions that can be copied/pasted (like about:plugins)?

Comment 11

[Thomas Bertels]

FIXED starting from
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre
and next builds.

Comment 12

[Robert Strong (they/them - no direct email)]

This can be fixed on the server side and nothing has changed on the client side... reopening.

Comment 13

[Thomas Bertels]

Reproduced with
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

WFM with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090504
Minefield/3.0a8pre
and following builds.

It's not fixed on the server side for me.

Can you reproduce with a recent build ?

Comment 14

[Robert Strong (they/them - no direct email)]

Thomas, whatever the case we are going to use this bug to provide a general fix.

Comment 16

[Dave Townsend [:mossop]]

The extension manager rewrite uses timeouts in its update checker to fix this.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, has this been landed with the initial rewrite? Do we have tests for it?

Comment 18

[Dave Townsend [:mossop]]

(In reply to comment #17)
> Dave, has this been landed with the initial rewrite? Do we have tests for it?

Yes, and I'm not sure we have a way to test timing out connections.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Testing timeouts should be possible with httpd. I will cc jeff walden who has implemented all the features and should be able to help us here.

As long we don't have tests and no such an invalid update url, I can't verify the fix.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Marking as verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101201 Firefox/4.0b8pre ID:20101201030318.

I have updated one of my installed add-ons and added the updateURL given in comment 0 to the install.rdf. We timeout after approx. one minute now.

(In reply to comment #19)
> Testing timeouts should be possible with httpd. I will cc jeff walden who has
> implemented all the features and should be able to help us here.

Jeff, can we delay the responses from httpd in some way to trigger a timeout on client side?

Comment 21

[Dave Townsend [:mossop]]

The code allows up to two minutes before timing out a request but then is longer than the timeouts for the test suites so I don't think we can actually verify this automatically.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

And there is no way to modify the timeout value? If it would be possible I could assume that we could put something in place for a manual test, even I have denied it at the moment.