133732 - Save as waiting for reply from server before showing dialog (should time out)

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is a spinoff from bug 118719.  We should not wait more than a second or so 
on the link checker.  If it takes longer than that to return, we should just 
cancel it, use the *.* filter and the application/octet-stream type or the 
document.contentType if we're saving a document.

Comment 1

[Akkana Peck]

Nominate nsbeta1 (guess it's too late for moz 1.0) since this makes it confusing
to use moz to download files -- I usually end up giving up and starting up
command-line ftp because with moz I can never tell if it's actually going to
show me a dialog or not.

Comment 2

[Samir Gehani]

Nav triage team: nsbeta1+, adt3

Comment 3

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 6

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So.  Apparently, IE does something like this (this from a conversation on IRC):

wilsonj> ok, tested IE 6
wilsonj> what IE 6 does is this:
wilsonj> it pops up the download window straight away, then it retrieves the
         content type from the server then it pops up the file save dialog
wilsonj> Then it starts the transfer
Neil> bz: you could almost use the progress dialog, just display that message in
      it
wilsonj> yes.
wilsonj> thats what I mean.
wilsonj> Show the progress dialog
wilsonj> And say "getting file information"
Neil> bz: and set the progressmeter to undetermined

This seems like the right way to go to me, personally... thoughts?

Comment 8

[Andrei Boros]

Considering the explained behaviour of IE, I'd like to add the following: 

- delaying the appearence of dialog boxes or new windows because they are 
waiting for events is not a good idea in my view. 
I performed an action and nothing happens. This is the way a user sees it. I 
don't consider IE's behaviour with respect to this a good one.
- Why the discrimination (even with a timeout) between Save As boxes and Open 
link in new window/tab? 
If I say Open in new window, Mozilla doesn't wait for a http reply of any kind, 
it creates the new window and lets it manage the request.
- The dialog should appear right away and display the status of the request and 
update this as the responses arrive, etc.
- Netscape 3&4 behaviour is what I consider normal and correct, that is: Save 
link as -> dialog appears rightaway, Save -> Save as window appears rightaway, 
Save As window shows "Contacting ..." then "Receiving" URL, Saving FILENAME, 
etc.

- One improvement that Mozilla might include to NS3&4 behaviour regarding Save 
As boxes that download files not already retrieved would be the following: 

Save link as puts in the dialog box the filename from the URL it wants to 
retrieve. Let's say that it's a CGI script that will send you a ZIP file. 
Content type and file extension from the received headers will differ from the 
ones in the URL that was requested. 
From this point there can be 3 ways to go:
1) continue with the name provided in the URL
2) rename to the name provided by the response headers
3) user chooses a new name.

This can be done either as a built-in automatic decision between 1) and 2), a 
configurable option that will set the default behaviour for such cases, or a new 
dialog, preferably system-modal popup, that will ask the user to decide, while 
in the background the download progresses.

Another thing: Netscape 3&4 behaviour is : while the user is being asked for the 
filename (and save location), the browser is working on retrieving the file in 
the background and if replies come and download starts before the user says 
"Save", by the time the Save as window appears, it already indicates some 
percentage of file retrieved (maybe the whole file if it's small and just dump 
it from cache to disk where instructed)

This strategy has good UI response and saves time.

Also, I can do it repeatedly for many link in the current page and return to the 
page for more, or to read or go somewhere else, fast, while downloads go on in 
the background. It's frustrating an slow to have such waiting times/timeouts. 
It's faster and more efficient with NS3&4 then. And with IE it will leave me 
wandering "where's my download?"

Comment 9

[Andrei Boros]

Mozilla 0.9.9 waits for the Save as dialog to complete, only then starts the 
download. 

Tried it compared to NS4 with the same link. 
Save As on the link, wait about 30 sec. and when I pressed save in Netscape, the 
save as window already showed about 30% of the file downloaded.
DId the same with Mozilla, waited longer, and it staterd from 0 when the Save as 
window appeard.

Comment 10

[[e-mail]]

This bug has high potential to utterly confuse users. How long it takes until
*some* reaction is shown after a "save as" attempt varies but it is usually 
long enough so that the user will try to do it several times. 
There might be a perfect way to solve this, but shouldnt there be 
done *something* in the meantime to let the user know that his request was
accepted, like popping up an intermediate progress window ("contacting host ...")? 
That would increase usability and is probably trivial enough to even
get it into 1.0 

BTW a similar thing is that "save link as" will just be a no-op without any
feedback when the user switched to offline... This can be completely
frustrating for users who have accidently switched the offline button and 
are not otherwise aware of the offline feature.
Give users feedback ...

Comment 11

[Boris Zbarsky [:bzbarsky]]

> That would increase usability and is probably trivial

Heh.  I'd never use the word "trivial" for any of this code.  I spent a few
hours at some point trying a dirty hack to do just that and completely failed...

The offline thing, please file.  That's very bogus.  :)

Comment 12

[Jonathan Wilson]

well it seems to be the simple fix for this problem is this:
1.create the download window before contacting the server
2.set the progress meter to some appropriate value
3.set some kind of UI string on the dialog to "getting file info for xyz"
4.get the headers & stuff
5.once the headers appear, show the save dialog. Make the save dialog always on
top of the download window somehow.
6.as soon as the headers are available and the save dialog is on screen, show
"saving file xyz" in the UI item instead of "getting file info for xyz".
Download should commence at the same time, similar to how mozilla currently
starts the dowload in the background if you leave the save dialog up.
7.once the user selects the filename in the save dialog, close the save dialog.
The download would then continue untill its finished or whatever, then the file
would be moved to whereever the user said to move it.

This is how I think it should work.
I intend to attempt an implementation of these 7 steps, accepting bug for now.
If anyone has any other suggestions about how this should work, let me know.
If anyone else is working on this or wants to take it over, again let me know so
I know to stop working on it :)

My method means that even if you have a really slow server, you can just wait
for it to either return the info or to return an error, there wont be a
percieved delay for the user.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> as soon as the headers are available and the save dialog is on screen, show
> "saving file xyz" in the UI item instead of "getting file info for xyz".
> Download should commence at the same time, similar to how mozilla currently
> starts the dowload in the background if you leave the save dialog up.

Mozilla in fact only does this if you click on the file and then select "save"
from the helper app dialog.  If you save by using "Save Image/Link/Page As" we
do not do that (and doing it would be not-so-easy-or-desirable in those cases;
see all the bugs connected with our "pre-downloading" behavior...).  I suggest
just saying "Waiting for user's filename input" or something similar in the
progress dialog while the filepicker is up.

The rest sounds great, though.

Possible problems:

1) The progress dialog is currently posed from inside nsWebBrowserPersist, as
   far as I can tell.... But I can't find where.  In any case, it would need to
   be posed _outside_ nsWebBrowserPersist and then hooked up as a listener to
   nsWebBrowserPersist, I guess....
2) This needs to play nice with the download manager.

nsIWebProgressListener and/or nsIProgressDialog may need to be extended a bit to
get this to work right.

Comment 14

[Jonathan Wilson]

It seems that the js code for save link as creates the header sniffer and then
only creates the filepicker after the header info is found. Persumably the code
then creates the progress dialog or the download manager dialog by calling
nsDownloadProxy->Init somehow.
Mabie if you were to:
1.modify the code such that nsDownloadProxy->Init is no longer passed the local
filename (since we dont have it yet)
2.change nsIDownloadManager so that it too isnt passed the filename, same with
the progress dialog. Also you change things so that its the download manager
and/or the progress dialog that accually talks to the server, gets the header
info and displays the filepicker.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Also you change things so that its the download manager and/or the progress
> dialog that accually talks to the server, gets the header info and displays the
> filepicker.

Let's make sure that the talking to the server thing happens in one place only, ok?

Comment 16

[Jonathan Wilson]

ok, it seems to me there are 3 different things that we need to care about here:
1.the adding of the download to the download manager
2.the display of the seperate progress window if the pref to cover this is set
to "dont display the download manager"
and 3.the display of the download manager if the pref is set to "display the
download manager"
Seems to me that we have to modify the various classes involved so that if the
pref is set to off then the progress dialog will appear and print the "getting
info" message.
If the pref is set to on, the download manager should appear. We need to figure out:
What to display, where to display it and when to display it.
What interfaces, classes and code need to be changed to handle those changes
then someone has to accually make the changes.

But we need to get the design downpat before we worry about the implementation.

Comment 17

[Dimitrios]

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

Comment 18

[Jesse Ruderman]

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

Comment 19

[Jesse Ruderman]

bz, I see a lot of bugs about pre-downloading (from bug 129923), but I don't see
one that's "Save Link Target As waits for filename before beginning download". 
The closest I found is bug 22796 aka bug 121029, but that's about the left-click
case (where the "what do you want to do with this file?" dialog might appear)
and not the "Save Link Target As" case.  Can you post the bug number here?

Comment 20

[Akkana Peck]

Jesse: I thought this was the bug for "Save Link Target As waits for filename
before beginning download".  Isn't "Save Link Target As" a specific case of
"Save As"?

Comment 21

[Boris Zbarsky [:bzbarsky]]

What Akkana said.  Note that this will just go away once we stop using the
filename from the server in the "save link as" case.... sad, but I see no good
easy way around it.

Comment 22

[Tim Burke]

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

Comment 23

[benc]

-> qa to sarah. I'm not sure why this was assigned to me. I'm also wondering if
the  bug ownership is correct.

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Matthias Versen [:Matti]]

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

Comment 27

[Boris Zbarsky [:bzbarsky]]

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

Comment 28

[Dimitrios]

Clearing a milestone already passed.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Fixed by bug 160454

Comment 30

[Martijn Wargers (dead)]

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