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.
Component: Browser-General → UE/UI
QA Contact: nobody → elig
Summary: Download window gets "lost" → Unknown File Type Download window gets "lost"
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.
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.)
I dunno, over to DanM for triage.
Putting on beta1 radar.
Putting on PDT+ radar for beta 1.
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
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
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
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
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.
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.
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.
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.
Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2
Target Milestone: M16 → M17
Moving non-feedback items out of UI: DF in preparation for handover to email@example.com. Not sure what component is correct, guessing XP Toolkit since trudelle made most recent comment.
Component: User Interface: Design Feedback → XP Toolkit/Widgets
nsbeta3-. Small percentage usage case. (Patient: "Doctor, it hurts when I do *this*." Doctor: "Don't do that").
Target Milestone: M17 → Future
Reporter: Is this fixed with a new build ?
no response from reporter marking worksforme (tried with win2k build 20010630.. (CVS opt)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
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.