192461 - Unable to cancel downlaod, or autoexpand downloads

Status: VERIFIED FIXED

(Camino Graveyard :: Downloading, defect, P2)

Description

[gulfie]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030205 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030205 Chimera/0.6+

I tried getting
http://www.publicintegrity.org/dtaweb/downloads/Story_01_020703_Doc_1.pdf from a
site that is getting spanked.  It took way to long, so I tried canceling it.  I
failed.  I used wget to get the pdf.  It worked, but had to reconnect a bunch of
times after timing out. 

Niether the 'X' or the 'cancel' button work, it just slowly extends the time it
will take to complete, and the current bandwith (93 bytes / sec). 

Reproducible: Didn't try

Steps to Reproduce:
I have way to much state in my browser to go ditching everything to test a
dowload thingie.  I'm a loozer.

Actual Results:  
well... I don't know any different, Iv'e always been a looozer.

Expected Results:  
Allow me to kill the damn thing. 


www.publicintegrity.org  reverse maps as host138.publicintegerity.org.

bash-2.05a$ nslookup host138.publicintegrity.org
Server:  ns5.attbi.com
Address:  204.127.202.4

Name:    host138.publicintegrity.org
Address:  63.72.70.138


bash-2.05a$ nslookup www.publicintegrity.org
Server:  ns5.attbi.com
Address:  204.127.202.4

Name:    www.publicintegrity.org
Address:  63.72.70.138




netstat:
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
<..>
tcp4       0      0  10.102.0.124.49450     host138.publicin.http  ESTABLISHED
<..>


After 10 minutes or so of a tcpdump, I've seen no packets for the site, or me.

Comment 1

[Greg K.]

WorksForMe using Chimera/2003021707. Both the X and Cancel buttons successfully
interrupt download.

gulfie, can you still reproduce this problem using a current nightly build?

Comment 2

[Chris Petersen]

I can reproduce this problem in the 2003-03-08-08 Camino trunk build. Clicking
the cancel or X buttons doesn't interrupt the file being transfered. Tested
under 10.2.4.

Comment 3

[Francis Mengjuei Hsieh]

I found the same problem in my system, too. I am using 10.2.4 and Camino Build
ID: 2003031307.

Comment 4

[Simon Fraser [no longer active]]

I know what this is

Comment 5

[Simon Fraser [no longer active]]

We need to sync with the changes from bug 129614 and bug 137676.

Comment 6

[Simon Fraser [no longer active]]

Attachment: Camino changes for downloading

These changes fix the cancelling of downloads, changes all downloads to be
'SaveToDisk' downloads, and adds code to auto-dispatch downloads in the front
end.

Changes for bug 129614 affected how cancels are handled. Previously, the front
end could cancel the webbrowserpersist, or the request, and then wait for a
final OnStateChange with an error code, at which point it could clean up. This
was nice, because cancels could be handled in the same way that other network
errors were.

Now, it seems that once nsExternalAppHandler::Cancel() has been called, it
doesn't send out any other notifications, so the frontend has to drive it's
"download finished or cancelled" logic from two places, and doesn't get a final
OnStateChanged that tells it that the download is done (with or without
success).

Comment 7

[Simon Fraser [no longer active]]

These changes fix autoexpanding downloads too.

Comment 8

[Simon Fraser [no longer active]]

Checked in.

Comment 9

[sairuh (rarely reading bugmail)]

using 2003.03.18.07, canceling now works, but initial autoexpand fails for some
files --rather than reopening this, i've filed bug 198076.

Comment 10

[Chris Petersen]

Verified in the 2003-03-18-08 Camino build.