Closed Bug 46318 Opened 24 years ago Closed 23 years ago

XPI download hangs until browser Stop button is clicked

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: tao, Assigned: dprice)

References

Details

(Keywords: intl) 

Build: 2000-07-24-09-m17

1. Go to release build dowbload page and click on langenus.xpi, 
2. The "software Installation" dialog popped up prompt the user what
   item to be downloaded.
3. Click on "Install" button to proceed/
4. A second dialog pops up prompting "downloading.."
5. The download process won't proceed unless you click on the "Stop"
   button in the Browser window.

Most users won't know this workaround.
nsbeta2 -- as I said, most users won't know this workaround and thought that
the process hang... very bad impression in their first attempt to try out the 
smartdown (theme/langpacks).
Keywords: nsbeta2
this sounds like a download dialog problem.  Don, does it look familiar?
Nope. I've never seen a case where clicking on the Stop button in the main 
browser will complete an installation.  Are these the only .xpi files that 
exhibit this problem?
This problem is reproducable on Linux (2000-08-24-06), too. --> XP
OS: Windows NT → All
Hardware: PC → All
please relnote
Keywords: nsbeta3, relnote2
Whiteboard: [nsbeta2-]
Adding myself to cc: list.
I can reproduce this by clicking on a link in the FTP display, but triggering 
via javascript (which is the recommended mechanism) works fine. A huge bummer, 
but nsbeta3- unless we run out of things to do.

Changing summary to reflect generic scope of the bug.
Summary: Langpack download hangs until click the "Stop" button in browser → XPI download hangs until browser "Stop" button clicked
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Adding Rob, Teruko, Frank and Bom-Shik to cc: list.
I hope we can find some time to this one during PR3 window.  This is a pretty
bad UE.  User will defintely think something is broken here.
Summary: XPI download hangs until browser "Stop" button clicked → XPI download hangs until browser Stop button is clicked
this is in bugscape as #1903

Hi, Dan:


Would you kindly provide the "javascript" trigger?



thx
Changed whiteboard status to reflect the status that was in its dupe
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3+]
Minusing if it's just the link. The js trigger is

InstallTrigger.install( {"pretty name": "url"} );

You could also use InstallTrigger.startSoftwareUpdate("url"); which gives a 
slightly less friendly UI and doesn't support the optional callback function.
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-]
This is an engine problem, not a package problem.
Assignee: ssu → dveditz
Component: Installer: XPI Packages → Installer: XPInstall Engine
QA Contact: gbush → jimmylee
Dan - We would kindly accept the minus (-), IF you could provide us with the
javascript trigger to workaorund this issue.  Otherwise, we are gonna scream 
pretty loud to fix this one.  The UE here is absolutely horrible!!! with a 
pretty high frequency rate. PLEASE ADVISE . . .
Hi, Jaime:


It seems that Dan provided the workaround in his previous comment. I will give a 
try.


thx
yes, the workaround appears to work on Mozilla M17 build.

Jaime:

Should we fix the download page to use this work around then?
Also note that if you are installing multiple languages at once, or a default 
pack with a lang pack, you definitely want to use the "install" method not the 
startSoftwareUpdate method.

  var xpiList = { "American English" : "langenus.xpi",
                  "German"           : "langdede.xpi",
                  "Japanese"         : "langjajp.xpi"  }
  function xpiCallback(url,status) {
     alert("Install of "+url+" returned "+status);
  }
  InstallTrigger.install( xpiList, xpiCallback );

Note the use of relative URLs (just the filename) assume the .xpi files are in 
the same directory as the web page serving that scriptlet. Not likely to be the 
case on Netcenter's servers, but a useful feature for simple sites. For 
Netcenter replace the .xpi filename with the full URL to the .xpi file
Tao - YES, we shopuld fix this. Since this is a java script issue, my assumtion 
is that Netcenter will have to implement the change in their pages, correct?

Adding Christine and Gregg toi cc: list.
yes. I already done so for the Mozilla Localization Project download page:

  http://www.mozilla.org/projects/l10n/mlp_status.html#contrib

This is also the link assoicated to "View|Set Language/Region>| Download More" 
in Mozilla M17.
gregg/christine - this is the java script fix for the download page we 
discussed during our meeting on Lang/Reg Selector.
Keywords: relnote3
Blocks: 42561
Adding Nhotta to cc: list.

Naoki - Can you take a look @ the javascript install trigger Dan gave us? We'd 
like to supply the Netcenter folks with the exact piece of code, so they can 
place it on a page and test it. Do you know Yung @ Int'l Netcenter? He's the guy 
who will be implementing it for us. 
Dan - Thanks for this server-side workaround, but I think this bug needs to be 
fixed by your team before we RTM the client. As you stated in the comment, and 
my assumption . . . generic scope of this issue (i.e. This will affect themes 
download, smart update, etc.), right? Please correct me, if I'm worng here. This 
is a very bad experience for the user.

This is nasty bug in our code, and we shouldn't place the responsbility on 
websites to fix this issue.

Adding TPringle, Sol and JohnG to cc: list.
Add Young Choi to cc: list   
Ummm, the JS trigger mechanism works fine as stated before.  The bug only lies 
in clicking directly on an ftp link but most websites should use the JS trigger 
anyways.  And the JavaScript trigger mechanism is not a workaround: it is the 
prescribed mechanism since it allows version checking etc.
The JavaScript trigger can not be accepted as a fix. The download need to proceed 
successfully whether it is linked directly to an ftp site or done so threw the 
use of a trigger. 

>This is nasty bug in our code, and we shouldn't place the responsibility on 
>websites to fix this issue.

You're welcome to mail pdt@netscape.com and seek exception approval for this 
bug, but at this point bugs with workarounds are getting shunted off right and 
left and I seriously doubt this one will be an exception.
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-] relnote-devel
On Unix, clicking on the browser stop button terminates the xpi installation,
rather than letting it continue; I get
Error loading URL
ftp://sweetlou.mcom.com/products/client/seamonkey/unix/linux/2.2/x86/2000-10-31-12-MN6/mozilla-xpi/chatzilla.xpi:
804b0002
in the xpinstall window.  I can't use xpinstall at all with the current branch
build, either through an xpinstall page or by double-clicking the .xpi file
directly.

I wouldn't care, except that this seems to be the only way of getting chatzilla.
Adding me to cc list.

I don't think has has anything to do with networking or Javascript, since the
problem exists when I load a local file url (/home/jg/mozilla/jre.xpi) in the
urlbar. The XPI download pops up, it installs, the XPI dialog closes and the
browser continues trying to load nothingness, I have to click stop. The XPI is
however successfully installed. Adding self to cc.

Nominating for nsbeta1 and adding intl keyword.
Keywords: intl, nsbeta1
Reassigning to Don
Assignee: dveditz → dbragg
ccing Kmurray, new installer PM.
*** Bug 62009 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta2-][nsbeta3-] relnote-devel → [nsbeta2-][nsbeta3-] relnote-devel [xpibug]
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9
p2 tasks
Priority: P3 → P2
Is anyone still seeing this?  I'm trying to reproduce it and everything seems to
be working.  I believe that this was related to ftp and the large amount of
changes that have gone into ftp recently have fixed it.

Regarding James Green's comment on 12/18/2000, are you experiencing this problem
when using file:/// ?  I've also tried this (with a much smaller install than
jre.xpi) and it is also working fine.
Status: NEW → ASSIGNED
I just successfully installed chatzilla from chatzilla.xpi.  There wasn't much
in the way of feedback (I ended up with a busy cursor that wouldn't go away) and
chatzilla didn't actually appear in the current session -- I had to exit and
restart before it appeared in the menus (is that intended?  I thought xpi files
were supposed to install "live") but on restart, I see that it installed
successfully and is working.  Woohoo!
Excellent!  Thanks Akkana.  The reboot is necessary with certain types of files.
Jar files are one of these. In fact, Chatzilla is the one I use for testing all
the time. Other kinds of files are held open by the OS but they can be renamed
(like shared libs) even if they're in use.  But .jar files can't so the little
replacement dance we do completed at the next startup.

I believe the busy cursor thing is not related to xpinstall.  The same thing
happens when you update bugs in bugzilla.  (on windows at least).
The chatzilla script currently registers chrome with the DELAYED_CHROME 
attribute (which ensures it's not visible until a browser restart) to work 
around some unrelated chrome bugs. We would very much like to be able to offer 
this "live" as soon as the install finishes.
I'm going to mark this as WORKSFORME because, well, it works for me and it seems
to be working for Akkana.  If anyone is still experiencing this problem, please
reopen the bug.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Build: 2001-02-16-09-Mtrunk(WIN), 2001-02-16-04-trunk(MAC), 
2001-02-16-08-Mtrunk(LINUX)

Works for me as well for all platforms.  Marking Verified!
Status: RESOLVED → VERIFIED
I'm seeing this again on mozilla builds when downloading talkback.xpi from
ftp.mozilla.org (currently 2001062909 but I've been seeing it for a week or so).

Reopening.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Don has moved to another group. Install bugs -> syd
Assignee: dbragg → syd
Status: REOPENED → NEW
If this doesn't get fixed for 0.9.3, there should probably be a release note for
it, methinks...
Syd - Cna we get this one moved to TM 0.9.4 and fixed.

Jon/Jimmy - Is this still happening?
Jaime, I only see this problem on the trunk, not on the branch.  When I tested
the 07-24 and 07-25 branch builds using the localized langjajp.xpi file, I did
not see this problem.  When I tested the 07-25-06-trunk build using the same
langjajp.xpi file, I saw that the download does hang until clicking Stop in the
browser.
I have reproduced this problem on the branch.  But this appears to occur
intermittantly.  I do not know the cause thus I cannot claim a reproducible case.
*** Bug 85043 has been marked as a duplicate of this bug. ***
I think this one is caused by bug 60910.  Let's not dupe them, one is the cause,
the other is the testable symptom
Depends on: 60910
Nominating.
Target Milestone: mozilla0.9 → ---
Blocks: 104166
Keywords: nsbeta1
This was working for a few days and then had broken again as of 2001112608.
Maybe something that got checked in around that time is to blame?
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.8
over to dprice
Assignee: syd → dprice
Keywords: nsbeta1, nsbeta2, nsbeta3, relnote2, relnote3
Whiteboard: [nsbeta2-][nsbeta3-] relnote-devel [xpibug]
dprice is on sabitcal. moving to next milestone.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
This one disappeared while I was testing the fix for.
http://bugzilla.mozilla.org/show_bug.cgi?id=60910
 
When that gets checked in, I think we can close this one too.
Just a reminder that this behavior is intermittant for me.  I saw it just
yesterday using a trunk build.
it looks like it only happens with http:// urls  

the fix for 60910 is in, marking this fixed too
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Build: 2002-03-19-10-trunk(WIN),2002-03-20-08-trunk(MAC),2002-03-20-08-trunk(LINUX)

I am not seeing this problem.  Bug 60910 has been fixed.  Marking Verified.
Status: RESOLVED → VERIFIED
"When you install language packs and other .xpi files, downloading pauses until
you click the browser's Stop button."

"You may need to press the Stop button for the installation process to complete."

Shouldn't those two sentences be removed from the release notes?
Sounds like that can come out of the release notes.  
relnote removed
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.