305631 - Extremely long delay when installing an extension before confirmation dialog

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Zach Lipton [:zach]]

Installing extensions is impossible with the latest builds. I get a hang when I
click the install link (before the confirmation dialog opens) and Gary on IRC
found that the countdown timer didn't count down, making it impossible to click
the install button.  

Seeing this on 20050823 on the branch.

Comment 1

[Zach Lipton [:zach]]

After a little further investigation: 

STR-
1. Click "install now" link to start extension installation
(spinning beachball of death for a good 50-60 seconds)
(confirmation dialog finally opens)

The countdown timer in the confirmation window also counts down in 10ths of a
second.

Apparently the issue may be server-side: Bob Clary could not reproduce when
installing an extension locally. Happens for me with any extension from
update.mozilla.org.

Comment 2

[Gary Elshaw]

The countdown goes into a perpetual loop: Install now to countdown ad infinitum

Comment 3

[Tracy Walker [:tracy]]

I've seen this on all platforms. But it's not 100% reproducable.  Sometimes the
confirmation dialog appears in an expected reasonbly short amount of time, 
sometimes not.  A few weeks ago I was told that this is probably server related
due to beginning of the month update hits on UMO.  

This delay can also cause confusion in that the user may click the "Install Now"
link again.  Which, if they wait long enough, eventually opens another
confirmation dialog for the same extension.

Comment 4

[Bob Clary [:bc] (inactive)]

In my case it is slightly different. Clicking on an extension on umo temporarily
locks the window (it won't redraw if hidden then shown again) for over a minute
before the window redraws. 

Comment 5

[Zach Lipton [:zach]]

Bob: I'm seeing the window (indeed, the entire browser) lock up for me on mac too. 

If nothing else, perhaps we need to display a progress bar or some sort of
indication of progress for extension downloading?

Comment 6

[Zach Lipton [:zach]]

Several other testers are seeing this on both branch and trunk over at
http://testrunner.mozilla.org/litmus/show_test.cgi?id=199.

Comment 7

[Tracy Walker [:tracy]]

The real failure discovered from those litmus reports is that the notification
toolbar isn't coming up when the site isn't on the whitelist. The first failure,
a crasher, I don't understand. The second is the failure to "add the site." But
that is because they aren't presented with the expected notification that the
site isn't allowed to install software.  I will file a bug on that.

Adding extension.mozdev.org to the whitelist for sites allowed to install
software then installing an extension works as expected.  No delay before the
confirmation dialog at extension.mozdev.org.  

Comment 8

[James Ross]

The crash one is not a real crash, it was a hang. I used a utility to force the
hung app to crash to get talkback, but naturally the report was TOTALLY USELESS.

The lack of "blocked" message is weeks old, too, from what I remember.

Comment 9

[Zach Lipton [:zach]]

Silver - As for the hang, I suspect that if you wait about a minute, it will
work (it was about 55 seconds for me when I timed the delay). It takes an
extremely long time before the confirmation dialog launches. 

Comment 10

[James Ross]

I know UMO is fucked at the moment, but I did wait at least a minute before
crashing Firefox on its behalf.

Comment 11

[Tracy Walker [:tracy]]

I filed bug 305648 for the missing notification toolbar/message.

Comment 12

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

UMO has a call to XMLHttpRequest in their install script which may be causing
this. Does this occur with other web sites when installing extensions using
installTrigger? It doesn't for me from http://spellbound.sourceforge.net/install
- I suspect this is similar to bug 304551 in that also involves UMO and
XMLHttpRequest but this is probably due to a change in XMLHttpRequest. In either
case this works for me on other sites that use installTrigger except UMO so this
is probably either an XMLHttpRequest or a UMO bug. Hopefully someone can figure
out which and assign it to the proper product and component so it gets attention.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050823
Firefox/1.0+ ID:2005082311

Comment 13

[Gary Elshaw]

There might be a combination of two separate bugs here. I just tried a local
drag and drop of an extension which failed to install. The result was the
looping of the countdown/confirmation dialog. 

Comment 14

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

Please search / file if not found a bug for that issue... they are separate.

Comment 15

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

I am no longer able to reproduce this. Is anyone still having the problem
installing extensions from UMO and if you are do you have the same problem from
http://spellbound.sourceforge.net/install ?

Comment 16

[Zach Lipton [:zach]]

According to tracy, this has been an intermittent issue over the past few weeks.
Even if we can't reproduce it now, it doesn't mean it's gone away...

Comment 17

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

Agreed, but if it is a UMO problem then for it to get attention the product and
component need to be changed to update and web site. If the problem is not
experienced when installing from http://spellbound.sourceforge.net/install then
chances are this is the case.

Comment 18

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

Forgot to add that earlier today I was able to reproduce from UMO and not from
the link I provided which is why I am asking for confirmation. So, if this is a
UMO specific issue then the bug's product and component can be changed so the
people that can fix this will be aware of it so they can fix it.

Comment 19

[Gary Elshaw]

Hi Robert, I tried installing SpellBound via the install page and the download
page and couldn't even get the warning about trusted sites. Just to be sure, i
tried installing Sage which stores the .xpi on ftp.mozilla.org, to no avail.
Drag and drop of any downloaded extensions puts Firefox into the loop i
mentioned earlier.

The delay in installing from UMO has dropped considerably since earlier this
morning (NZ time), however the looping still occurs.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050823
Firefox/1.0+ (OS X 10.4.2)

Comment 20

[Tracy Walker [:tracy]]

The problem didn't occur with the spellbound site or extensionsmirror.nl. I am
also not able to reproduce at UMO at this hour.   I have been seeing it fairly
consistantly at UMO during smoketesting. I will try all three again in the morning. 

Comment 21

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

Gary - the missing warning is a known bug (see bug 304727 which bug 305648 was
duped to)

Once added to the allowed sites list the time for the confirmation dialog (e.g.
the xpinstall dialog) should be comparable to the time it takes to display the
save as dialog (of course this requires that you have prefs set accordingly for
downloading files) when downloading a file.

Note: last I checked extensionsmirror.nl did not use installTrigger as UMO and
the spellbound site does. Also, both UMO and the spellbound site have the xpi's
hosted elsewhere so testing against the spellbound site should be very similar
except that it installs two xpi's.

Comment 22

[Gary Elshaw]

Thanks for heads-up for bug 304727. I added spellbound.sourceforge.net to my
allowed sites and the xpinstall dialog came up fine, however it still won't
install, i keep getting exactly the same result. I've been sick with the flu for
the last week and are beginning to think maybe i've been hedging my language -
currently, there is no way to install new extensions with branch (updates work
fine), the extensions install manager is very broken. :)

I'll butt out now.

Comment 23

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

Gary - what you are describing is different from what I and many other see on
the branch and it is different than the original bug reported and experienced by
Zach. As was stated in comment #14 "Please search / file if not found a bug for
that issue... they are separate." I suspect you may be experiencing bug 305694.

Comment 24

[Tracy Walker [:tracy]]

I haven't been able to reproduce this for the past couple days.

Comment 25

[Tracy Walker [:tracy]]

This has returned on all platforms during todays DP branch smoketests. For a few
days last week when this worked fine.  We're getting the long delay at UMO. I
tested the spellbound site immediately following the smoketest and found that we
do not have the delay at that site.  

Comment 26

[Tracy Walker [:tracy]]

Might this also be the culprit causing hangs in extension check while running
application update?

Comment 27

[Benjamin Smedberg]

> Might this also be the culprit causing hangs in extension check while running
> application update?

No, that is a different bug and should be filed separately if it's not already.
This bug is about the use of a synchronous XMLHttpRequest on addons.mozilla.org
which is not necessary at all: flipping the switch to use an async request
should do the exact same thing and prevent the hang in this case.

Comment 28

[Tracy Walker [:tracy]]

That hang is probably bug 288054 or bug 290960. Thanks Ben. 

Comment 29

[alanjstr]

Does anyone see a reason to keep the XMLHttpRequest?  It certainly doesn't do
whatever it was supposed to do.

Comment 30

[Dave Miller [:justdave]]

Requesting blocking pre request from Tracy

Comment 31

[Michael Morgan [:morgamic]]

Is this simply a matter of changing:
p.open("GET", "'.WEB_PATH.'/core/install.php?uri="+aEvent.target.href, false);

To:
p.open("GET", "'.WEB_PATH.'/core/install.php?uri="+aEvent.target.href, true);

Comment 32

[Asa Dotzler [:asa]]

Rob, can you help us drive this forward?

Comment 33

[Tracy Walker [:tracy]]

As seen with Linux and Mac builds from this morning 20050923

Extension/Theme installs work without hang or delay.
Page loading is back to normal (not blazing, but not deadly slow either).

Comment 34

[Frank Yan (:fryn)]

Moz Update still really slow on WinXP:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050927
Firefox/1.4 ID:2005092706

and hang still occurs for extension installation

Comment 35

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

(In reply to comment #32)
> Rob, can you help us drive this forward?
In regards to the XMLHttpRequest issue - Michael just checked in a patch I
submitted in bug 295366. I wouldn't be surprised if there are other issues
possibly involving network utilization but once the patch goes live
XMLHttpRequest should not be to blame.

Comment 36

[Asa Dotzler [:asa]]

Robert, is this better now? Do we still need to block on this.

Comment 37

[Michael Morgan [:morgamic]]

The patch was committed to CVS and it was updated in production, so if it is not
resolved, it could be that the issue is the install.php script itself that the
JavaScript request calls.  That script is set to be modified by a patch I am
finishing up that is attached to bug 308691.  That bug deals with scalability
issues stemming from maintenance code unnecessarily being run everytime someone
downloads any addon.  It could be that these issues are related.

Comment 38

[Asa Dotzler [:asa]]

marking as fixed so we can get a verification. Tracy and Marcia, can you help
out here with some testing? Thanks.

Comment 39

[Tracy Walker [:tracy]]

Tested with Windows and Linux Firefox mozilla1.8 branch builds.  The extension
confirmation dialog is appearing immediately as expected.  Also no longer seeing
slowness with general AMO page loading.

Comment 40

[Dave Miller [:justdave]]

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

Comment 41

[Aishwarya]

Tested with Windows and Linux Firefox mozilla1.8 branch builds.  The extension
confirmation dialog is appearing immediately as expected.  Also no longer seeing
slowness with general AMO page loading.

Comment 42

[Lukas Blakk [:lsblakk] use ?needinfo]

no idea why this 7 year old bug just got activity, but it certainly isn't a tracking15 bug :)