Closed Bug 305631 Opened 19 years ago Closed 19 years ago

Extremely long delay when installing an extension before confirmation dialog

Categories

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

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: zach, Assigned: morgamic)

References

Details

(Keywords: verified1.8) 

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.
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.
Flags: blocking1.8b4?
OS: MacOS X → All
Hardware: Macintosh → All
Summary: Hang or loop makes extension installation impossible → Extremely long delay when installing an extension before confirmation dialog
The countdown goes into a perpetual loop: Install now to countdown ad infinitum
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.
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. 
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?
Several other testers are seeing this on both branch and trunk over at
http://testrunner.mozilla.org/litmus/show_test.cgi?id=199.
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.  
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.
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. 
I know UMO is fucked at the moment, but I did wait at least a minute before
crashing Firefox on its behalf.
I filed bug 305648 for the missing notification toolbar/message.
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
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. 
Please search / file if not found a bug for that issue... they are separate.
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 ?
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...
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.
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.
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)
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. 
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.
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.
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.
Assignee: nobody → mconnor
Flags: blocking1.8b4? → blocking1.8b4+
I haven't been able to reproduce this for the past couple days.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee: mconnor → Bugzilla-alanjstrBugs
Status: REOPENED → NEW
Component: Extension/Theme Manager → Web Site
Flags: blocking1.8b4+
Product: Firefox → Update
QA Contact: extension.manager → web-ui
Version: 1.5 Branch → 1.0
Might this also be the culprit causing hangs in extension check while running
application update?
> 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.
That hang is probably bug 288054 or bug 290960. Thanks Ben. 
Does anyone see a reason to keep the XMLHttpRequest?  It certainly doesn't do
whatever it was supposed to do.
Depends on: 306643
Requesting blocking pre request from Tracy
Flags: blocking1.8b5?
Assignee: Bugzilla-alanjstrBugs → morgamic
Flags: blocking1.8b5? → blocking1.8b5+
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);
Rob, can you help us drive this forward?
Depends on: 309484
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).
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
(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.
Robert, is this better now? Do we still need to block on this.
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.
marking as fixed so we can get a verification. Tracy and Marcia, can you help
out here with some testing? Thanks.
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8
No longer depends on: 309484
*** Bug 309484 has been marked as a duplicate of this bug. ***
Keywords: fixed1.8 → verified1.8
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.
tracking-firefox15: --- → ?
no idea why this 7 year old bug just got activity, but it certainly isn't a tracking15 bug :)
tracking-firefox15: ? → ---
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.