46318 - XPI download hangs until browser Stop button is clicked

Status: VERIFIED FIXED

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

Description

[tao]

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.

Comment 1

[tao]

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).

Comment 2

[Sean Su]

this sounds like a download dialog problem.  Don, does it look familiar?

Comment 3

[dbragg]

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?

Comment 4

[tao]

This problem is reproducable on Linux (2000-08-24-06), too. --> XP

Comment 5

[leger]

please relnote

Comment 6

[Jaime Rodriguez, Jr.]

Adding myself to cc: list.

Comment 7

[Daniel Veditz [:dveditz]]

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.

Comment 8

[Jaime Rodriguez, Jr.]

Adding Rob, Teruko, Frank and Bom-Shik to cc: list.

Comment 9

[Jaime Rodriguez, Jr.]

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.

Comment 10

[Rob Spain]

this is in bugscape as #1903

Comment 11

[tao]

Hi, Dan:


Would you kindly provide the "javascript" trigger?



thx

Comment 12

[Rob Spain]

Changed whiteboard status to reflect the status that was in its dupe

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Daniel Veditz [:dveditz]]

This is an engine problem, not a package problem.

Comment 15

[Jaime Rodriguez, Jr.]

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 . . .

Comment 16

[tao]

Hi, Jaime:


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


thx

Comment 17

[tao]

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

Jaime:

Should we fix the download page to use this work around then?

Comment 18

[Daniel Veditz [:dveditz]]

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

Comment 19

[Jaime Rodriguez, Jr.]

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.

Comment 20

[tao]

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.

Comment 21

[Jaime Rodriguez, Jr.]

gregg/christine - this is the java script fix for the download page we 
discussed during our meeting on Lang/Reg Selector.

Comment 22

[Jaime Rodriguez, Jr.]

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. 

Comment 23

[Jaime Rodriguez, Jr.]

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.

Comment 24

[Christine Sanders]

Add Young Choi to cc: list   

Comment 25

[Samir Gehani]

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.

Comment 26

[Rob Spain]

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.

Comment 27

[Daniel Veditz [:dveditz]]

You're welcome to mail [e-mail] 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.

Comment 28

[Akkana Peck]

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.

Comment 29

[alexander]

Adding me to cc list.

Comment 30

[James Green]

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.

Comment 31

[Jaime Rodriguez, Jr.]

Nominating for nsbeta1 and adding intl keyword.

Comment 32

[Daniel Veditz [:dveditz]]

Reassigning to Don

Comment 33

[Todd Pringle]

ccing Kmurray, new installer PM.

Comment 34

[Daniel Veditz [:dveditz]]

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

Comment 35

[Daniel Veditz [:dveditz]]

Moz 0.9 tasks

Comment 36

[dbragg]

p2 tasks

Comment 37

[dbragg]

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.

Comment 38

[Akkana Peck]

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!

Comment 39

[dbragg]

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).

Comment 40

[Daniel Veditz [:dveditz]]

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.

Comment 41

[dbragg]

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.

Comment 42

[Jimmy Lee]

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!

Comment 43

[Dave]

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.

Comment 44

[Daniel Veditz [:dveditz]]

Don has moved to another group. Install bugs -> syd

Comment 45

[Dave]

If this doesn't get fixed for 0.9.3, there should probably be a release note for
it, methinks...

Comment 46

[Jaime Rodriguez, Jr.]

Syd - Cna we get this one moved to TM 0.9.4 and fixed.

Jon/Jimmy - Is this still happening?

Comment 47

[Jon Rubin]

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.

Comment 48

[Jimmy Lee]

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.

Comment 49

[Daniel Veditz [:dveditz]]

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

Comment 50

[Daniel Veditz [:dveditz]]

I think this one is caused by bug 60910.  Let's not dupe them, one is the cause,
the other is the testable symptom 

Comment 51

[Jimmy Lee]

Nominating.

Comment 52

[Dave]

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?

Comment 53

[Syd Logan]

over to dprice

Comment 54

[chris hofmann]

dprice is on sabitcal. moving to next milestone. 

Comment 55

[dprice (gone)]

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.

Comment 56

[Jimmy Lee]

Just a reminder that this behavior is intermittant for me.  I saw it just
yesterday using a trunk build.

Comment 57

[dprice (gone)]

it looks like it only happens with http:// urls  

the fix for 60910 is in, marking this fixed too

Comment 58

[Jimmy Lee]

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.

Comment 59

[Vadim Berezniker]

"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?

Comment 60

[dprice (gone)]

Sounds like that can come out of the release notes.  

Comment 61

[timeless]

relnote removed