22427 - Download stops in minimised window, download window gets lost

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Joseph Elwell]

Try this on M12. Build 1999122023 WinNT.
1) Launch Mozilla.
2) Goto URL.
3) Click on "Windows" to download latest nightly build of windows.
4) Before the unknown file type window opens minimize mozilla.
5) Watch as the Unknown file type window appears in the task bar.
6) Click to restore the Unknown file type window.
*notice that it won't restore*

Is it really there? Only mozilla knows. And mozilla acts as if nothing happened,
you can continue browsing as per normal in the main window. I have a feeling
that the URL isn't unique - this probably happens on any download.

Comment 1

[Sean Richardson]

This is something that is done ... if the user will be doing nothing more
with the browser while the download is happening, why keep it visible?

Confirmed with 2000-01-12-10-M13 nightly binary on Windows NT 4.0sp3

After clicking to trigger the download, and before the "Unknown File Type"
dialog window appears, the status bar shows messages related to the startup
of an FTP transfer. The bug only appears if the browser window is minimised
during this period, before the dialog appears.

Guessing that the dialog wants to initialize something or other based on its
parent browser window, but "Saving Location"-type dialogs are never modal, so
this should not be necessary.

Also, no "Saving Location"-type dialog should ever appear minimised, regardless
of anything else ... users expect to see some initial transfer activity, after
which the *user* may choose to minimise the dialog.

Here is the console output that appeared while following the steps:
  >Document http://www.mozilla.org/ loaded successfully
  >Document: Done (4.116 secs)
  >DocLoaderFactory: Unable to create ContentViewer for command=view,
  >content-type=application/octet-stream
  >Document: Done (6.379 secs)
  >WEBSHELL+ = 5
  >Error loading URL
  >ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip
Actually, the exact same lines show if the browser is not minimised in step 4.

Closing the browser window normally did not remove the "Unknown File Type"
dialog from the taskbar, and the console output stopped at a WEBSHELL- = 3 line
without actually finishing (no command prompt appeared. ctrl-c in the WinNT
cmd.exe window from which I had started Mozilla fixed that, and returned the
memory Mozilla had been using. So it looks like this is also causing a crash on
exit.

Changing component from "Browser-General" to "UE/UI" - no idea which component
and what owner should see this report, and this is a UE problem.

Comment 2

[Eli Goldberg]

Peter, might this belong to someone in your group? (Not sure if it the toolkit
has a bug, or if the browser is using the toolkit incorrectly.)

Comment 3

[Peter Trudelle]

I dunno, over to DanM for triage.

Comment 4

[Peter Trudelle]

Putting on beta1 radar.

Comment 5

[leger]

Putting on PDT+ radar for beta 1.

Comment 6

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 7

[Dan M]

  Can't reproduce with today's NT source. What I see when I try to reproduce it 
leads me to believe the download dialog disappeared for the bug's reporter 
because the download was in fact stopped.
  Under normal conditions, a network channel fires up, starts reading, after 
reading the response header realizes there's a download coming, and among other 
things, spins up a download dialog.
  However if the browser is quickly minimized after clicking the download link, 
necko never finishes reading the response header. In fact 
nsFileChannel::OnStartRequest never fires until after the browser window is 
restored. And even then, the header is never read 
(nsHTTPResponseListener::FinishedResponseHeaders never fires.)
  Perhaps this is by design. It seems like it's probably a bug. I don't know why 
network I/O would apparently stop for a minimized window. Assigning to Warren as 
a way of attracting his attention.

Comment 8

[Warren Harris]

Sounds like when the window gets minimized, events don't get processed for it 
anymore. At the very least, we have to keep dealing with PLEvents so that data 
gets delivered from necko. Can you confirm that?

Comment 9

[Joseph Elwell]

Originally the "Unknown File Type" window could not be restored. ie. it would
start minimised and windows would not let you open the window. However, now you
can restore the "Unknown File Type" and click on Save & choose a save location.
The file will download fine. The only bug now seems to be the save window starts
off minimised and won't restore. This was tested on winNT 2000021408

Comment 10

[Peter Trudelle]

removing PDT+ and beta1 nomination. This is an unlikely edge-case with severe
timing constraints, the kind of bug that is encountered mainly by QA. It took me
6 tries to minimize the window fast enough to reproduce it, and then only after
I had resized the window so the minimize control was close to the download link.
Even then, the problem is minor, and the window can still be closed using its
taskbar entry context menu. We should fix this, but there is no way we'd hold
beta for it.

Comment 11

[Joseph Elwell]

I don't think it's so bad either; however I do think that the PDT team should be 
the ones to decide whether it's PDT+ or not.

Comment 12

[Sean Richardson]

There is no problem reproducing this if a modem is in the network between
the user and the server, and the server is at all busy and an FTP session
must be started. This can entail a wait of several to 20 seconds waiting
for the multiple round-trips involved in setting up the download, even if
once it starts the download will proceed at the full rate of the modem
connection - regardless of the browser make and version.

The links to the nightlies on the page at http://www.mozilla.org/ have been 
changed from ftp://ftp.mozilla.org/... to http://ftp.mozilla.org/... 
which avoids the FTP login process, speeding up the appearance of the
"Unknown File Type" dialog markedly: if the URL of the file to be downloaded 
is changed to start with ftp://, this should be easier to reproduce on a
machine with a fast link to the 'net.

Comment 13

[Joseph Elwell]

I reported this, and I'm on a business network which I assume is at least T3. As 
a matter of fact: I download mozilla regularly at 170KB/sec. *shrug* so I agree 
with sidr that a fast network won't make any difference.

Comment 14

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 15

[Eli Goldberg]

Moving non-feedback items out of UI: DF in preparation for handover to 
[e-mail]. Not sure what component is correct, guessing XP Toolkit 
since trudelle made most recent comment.

Comment 16

[Peter Trudelle]

nsbeta3-.  Small percentage usage case.  (Patient: "Doctor, it hurts when I do
*this*." Doctor: "Don't do that").

Comment 17

[Matthias Versen [:Matti]]

Reporter: Is this fixed with a new build ?

Comment 18

[Matthias Versen [:Matti]]

no response from reporter
marking worksforme (tried with win2k build 20010630.. (CVS opt)

Comment 19

[Joseph Elwell]

tested with 07/21/2001 comm branch bits.
either it works, or the browser is too fast for me now.