Closed Bug 44176 Opened 25 years ago Closed 25 years ago

Odd download behavior; progress window never shown

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mscott)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [nsbeta3-][pdtp2][rtm++]se-radar fix in hand)

Attachments

(1 file)

the fix
14.32 KB, patch
Details | Diff | Splinter Review
Build ID: 2000062708 Steps to Reproduce: (1) Go to Mozilla.org (2) Click on the Windows link at the bottom (in the Nightly Builds section) For me, this didn't bring up either the unknown application dialog or the progress window. Instead, the progress meter started going...when it got to 100, the download was apparently done--WinZip opened up. The fact that WinZip (my helper app) opened without me having to specify is great, with two issues: (1) no progress window appeared (2) I didn't get to choose the file name I wanted. The first time I tried it the filename was test.zip I tried it again in an attempt to reproduce, and it was test-2.zip
nominating for beta2: * we give the user no highly visible sign that anything's happening (it's highly unexpected that the browser progress meter would measure the progress of a download) * we give the user no info about the file he's downloading, how much time left, etc. * people on slower dial-up connections (i'm on DSL) might think no download is happening.
Keywords: nsbeta2, regression
cc law -- I see you made a helper app checkin, could this be related at all (for whatever reason, bonsai isn't displaying the diff of that checkin)
I just added that file, thus no diff (I guess). That checkin is part of the fix for this bug, which is basically a dup of 43583. mscott recently added code to launch helper apps (that code will be opening this new dialog first, when the dialog is ready). I didn't think he had it wired up yet so it would actually launch winzip for .zip files. This dialog should take care of giving the user feedback about the fact that the download is occurring. At some point, we will actually show a progress meter (the same as you get if you do "Save File..." from the unknown content dialog). When the file is opened (versus saved to disk) it goes to a temporary file and the name is arbitrary (I think). That may account for "test," then "test-2". I'm cc:ing mscott so he can add more. Given this, please comment on how you'd like to see this bug resolved. I'm reassigning the bug to myself. It isn't a networking problem, until such time as you try to download lots of big files, all at the same time (that's an inside joke :-).
Assignee: gagan → law
Thanks for the clarification -- in that case, should this just be marked invalid or dup?
Sorry, I should have been more explicit. If the reporter is happy with my hand-waving explanation and will be content to open a new bug if the promised "helper app lauch confirmation" dialog isn't sufficient, then mark it a dup. Otherwise, it should be amended to read something like "the dialog described in bug 43583 sucks because ..." (at which point we'll *then* resolve it as INVALID :-). I'm only half-kidding about that. The runway is shortening so there isn't likely to be too many more revolutionary developments.
well, I'm the reporter :) I'll leave this open til 43583 is fixed and then reevaluate, but removing beta2 nomination
Keywords: nsbeta2
Here's the scoop: Last Thursday night, helper app support was turned on in the backend. That's why winzip launches automatically for you. As Bill mentioned the UI is still being worked on. Once that's added, you'll first get a prompt asking you if you want to open the application using winzip, open using another application, or save to disk. But right now we just launch it right away 'cause we don't have the dialog yet.
*** Bug 45269 has been marked as a duplicate of this bug. ***
*** Bug 46312 has been marked as a duplicate of this bug. ***
*** Bug 46312 has been marked as a duplicate of this bug. ***
*** Bug 46930 has been marked as a duplicate of this bug. ***
Well, since I reported a dup-of-a-dup, I'll add my observations: I don't get a Save-As dialog, after the 'Choose handling' dialog. Since I elect to Save to Disk, I see the behavior in this bug. The problem being, I DON'T get the helper app starting up when the file is downloaded, even if there is one. The file simply disappears. Is this believed to be behavior that can sit until after beta 2?
From bug 46930 If you choose to save the file it starts the download without asking where to save it. At that point it should behave like "save link as"
here is what i see, when using branch commercial bits on winNT [2000.08.01.04-m17] --lemme know if what i see is the same as this bug, or something else. thx! 1. go to mozilla.org 2. scroll down to the Nightly Build section and click Windows link. 3. i get the dialog [labelled "Downloading"] which asks me whether to open using WinZip (selected by default), or to save to disk. 4. i select Save to Disk, then 5. click the Choose button to change the download location to my desktop 6. click the OK button. observed results: the Downloading dialog goes away, but i'm expecting the [previously seen in earlier builds] progress *dialog*. instead the progress meter in the *statusbar* is the only indication i see. another test (again, let me know if this is *this* bug, or another one): same steps, except that i keep the default setting "Open using: WinZip." result: sometimes WinZip actually launches (expected, yay), but occaisionally i get the same result of only the progress meter in the statusbar changing. known problem?
Keywords: mostfreq, relnote2
The first thing you mentioned is definitely this problem. No progress dialog appears, so not only does the user have no details about the download, but most won't realize that the progress meter in the statusbar is actually displaying the progress of their download (so they'll think nothing happened and the download failed). I'm not sure about the erratic winzip behavior. Sounds like it could be a different bug...
blake: thanks for the info about the 1st problem i see! i realize however, that i missed mentioning a step, which might be yet more bug[s] --pls lemme know if they are: 5a. at step 5 above: the Choose button is actually *greyed-out* but clickable! i really didn't select the download location here (my confusion, going thru this too quickly), even though i attempted to anyhow in the next step... 5b. i just selected a location, then ended up clicking Cancel to dismiss it. 6a. so after this futile exercise i clicked the OK button (in the XP Download dialog) 6b. *then* a native dialog appears titled "Enter name of file to save to" where i selected the real download location... 6c. if the file already exists in the same location, i am *not* asked whether i wish to replace it --instead, the filename itself is incremented. 5a and 6c sound like separate bugs from this one --but let me know if they aren't. NOTE: if i *don't* go thru steps 5a and 5b, i *never* get the dialog in 6b --ie, i never get a choice as to *where* to save the file. known or new bug?
changing to all, since i see this on linux, too (as well as winnt and kinda on the Mac --see my comments in bug 46836.)
Severity: normal → major
OS: Windows 98 → All
Hardware: PC → All
No longer blocks: 47358
Blocks: 46313
nominating for nsbeta 3
Keywords: nsbeta3
nav triage team: 3 issues really: (1) no progress window appeared (2) I didn't get to choose the file name I wanted. The first time I tried it the filename was test.zip I tried it again in an attempt to reproduce, and it was test-2.zip (3) No way to cancel the download (could hose you with a big file) reassigning to mscott, recommending nsbeta3+ (UI and nav team recommend this).
Assignee: law → mscott
John, what build were you using?? (1) is the only problem I see and that's what this bug is supposed to be tracking. (2) I'm always asked to choose a file (we download while we wait for you to choose the file though) (3) there's a big cancel button in the helper app dialog you can hit cancel on. Also, if you decide to save to disk, when the file picker dialog is up there's another cancel button you can hit as well. So I give you two spots to cancel the download from.
I think the first two points he stated were just excerpts from my original bug. But yes, point (1) is the only really valid one. Point (2) was something I said originally, but Bill explained that the filename used when the user decided to open (rather than save to disk) was arbitrary (and this is pretty much correct -- IE just saves to a temp directory, without giving you a chance to save...which makes sense, since you didn't choose Save to Disk). Point (3) isn't really true. There is a way to cancel the download if you choose Open (just press Stop), but of course a cancel button would be more desirable. However, when point (1) is fixed by making the progress window show, this will be fixed anyways (the progress window has a cancel button).
*** Bug 47588 has been marked as a duplicate of this bug. ***
since this still occurs (using 2000.09.13.12 mozilla on win98, clicking the Windows nightly build link on mozilla.org, etc.), i'm just issuing a friendly ping to see what the status is on fixing this? thx much!
Gagan: if this is going to be +'d, it needs to be +'d _now_ (even so, I don't see how there will be time to get to this). If you minus it, please add `relnote3' and nominate for rtm.
I am not the one making that call but I would recommend a plus to PDT.
*** Bug 47799 has been marked as a duplicate of this bug. ***
On the assumption this bug is about creating a download progress dialog, marking nsbeta3+, P2.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
This bug occurs on the Mac in full. If this doesn't get fixed and has to be relnoted, here's a workaround so it's not a complete disaster: copy the link to the file you're trying to download, choose "Open Web Location" from the file menu, paste the URL, hit OK (you can choose to open in another window or not, it doesn't matter) and voila! You get the "you're about to download a file of type x", press "Save File...," choose a name and location and the progress window appears. I've only been able to test this under Mozilla M18 2000091808, Mac OS 9.0.4.
Sheesh, I feel stupid. Forgot contextual menus were complete (can right/control-click and choose "Save Link as"). You can also enter the URL in the location bar manually and it works right. Apparently, this bug only happens when you try to download the file by just clicking on the hyperlink. But the download/progress dialog IS there.
Whiteboard: [nsbeta3+] → [nsbeta3+] se-radar
pdt agrees p2.
Whiteboard: [nsbeta3+] se-radar → [nsbeta3+][pdtp2]se-radar
I have a fix for this. I impelemented a stand alone progress dialog which the helper app download now runs inside of. Pending a friendly code review from law and some others tomorrow we should be good to go....
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3+][pdtp2]se-radar → [nsbeta3+][pdtp2]se-radar fix in hand
will need to talk to pdt about getting this in branch as well
*** Bug 45873 has been marked as a duplicate of this bug. ***
selmer and i decided to hold off on this fix until rtm since we are so close to getting the beta out the door. I didn't get it checked by the deadline of last thursday at midnight.
Keywords: rtm
nsbeta3- then
Whiteboard: [nsbeta3+][pdtp2]se-radar fix in hand → [nsbeta3-][pdtp2]se-radar fix in hand
rtm+, we need this for save attachment and for general usability throughout the product.
Whiteboard: [nsbeta3-][pdtp2]se-radar fix in hand → [nsbeta3-][pdtp2][rtm+]se-radar fix in hand
*** Bug 54656 has been marked as a duplicate of this bug. ***
mscott, can you attach the patch and list the reviewers in order to get the rtm++.
Attached patch the fix — — Splinter Review
sr=rpotts This puppy is ready to go pending the rtm++ status....
*** Bug 53227 has been marked as a duplicate of this bug. ***
just to re-iterate: the uriloader changes sr=rpotts the xpfe\ucth changes: r=law, sr=alecf
PDT marking [rtm++]
Whiteboard: [nsbeta3-][pdtp2][rtm+]se-radar fix in hand → [nsbeta3-][pdtp2][rtm++]se-radar fix in hand
Fixed on both the tip and the branch. You now get a stand alone progress window that will come up after you dismiss the helper app launcher dialog. Note: This dialog only comes up if we haven't already finished downloading the content while the user was presented with the helper app dialog. Be sure to test cancel from the progress dialog as well.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified on the branch WinNT 2000100908 Mac os9 2000100910 Linux 2000100910 need to check trunk
Keywords: vtrunk
Verified Fixed on trunk builds linux 101708 RedHat 6.2 win32 101704 NT 4 mac 101704 Mac OS9 Setting bug to Verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: