Download stops in minimised window, download window gets lost




19 years ago
17 years ago


(Reporter: Joseph Elwell, Assigned: Dan M)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-], URL)



19 years ago
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.


19 years ago
Component: Browser-General → UE/UI
QA Contact: nobody → elig
Summary: Download window gets "lost" → Unknown File Type Download window gets "lost"

Comment 1

19 years ago
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 loaded successfully
  >Document: Done (4.116 secs)
  >DocLoaderFactory: Unable to create ContentViewer for command=view,
  >Document: Done (6.379 secs)
  >WEBSHELL+ = 5
  >Error loading URL
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

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.


19 years ago
Assignee: nobody → trudelle

Comment 2

19 years ago
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.)


19 years ago
Assignee: trudelle → danm

Comment 3

19 years ago
I dunno, over to DanM for triage.


19 years ago
Target Milestone: M14

Comment 4

19 years ago
Putting on beta1 radar.
Keywords: beta1

Comment 5

19 years ago
Putting on PDT+ radar for beta 1.
Whiteboard: [PDT+]

Comment 6

19 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback


19 years ago
Whiteboard: [PDT+] → [PDT+] 2/15

Comment 7

19 years ago
  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.
Assignee: danm → warren
Summary: Unknown File Type Download window gets "lost" → Download stops in minimised window, download window gets lost
Whiteboard: [PDT+] 2/15 → [PDT+]
Target Milestone: M14

Comment 8

19 years ago
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?
Assignee: warren → danm

Comment 9

19 years ago
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


19 years ago
Target Milestone: M14

Comment 10

19 years ago
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.
Keywords: beta1
Whiteboard: [PDT+]

Comment 11

19 years ago
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

19 years ago
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 have been 
changed from to 
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

19 years ago
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.


19 years ago
Target Milestone: M14 → M15


19 years ago
Target Milestone: M15 → M16

Comment 14

19 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 15

19 years ago
Moving non-feedback items out of UI: DF in preparation for handover to Not sure what component is correct, guessing XP Toolkit 
since trudelle made most recent comment.
Component: User Interface: Design Feedback → XP Toolkit/Widgets


18 years ago
Keywords: nsbeta3

Comment 16

18 years ago
nsbeta3-.  Small percentage usage case.  (Patient: "Doctor, it hurts when I do
*this*." Doctor: "Don't do that").
Whiteboard: [nsbeta3-]
Target Milestone: M17 → Future


18 years ago
QA Contact: elig → jrgm
Reporter: Is this fixed with a new build ?
no response from reporter
marking worksforme (tried with win2k build 20010630.. (CVS opt)
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 19

17 years ago
tested with 07/21/2001 comm branch bits.
either it works, or the browser is too fast for me now.
You need to log in before you can comment on or make changes to this bug.