Closed Bug 142664 Opened 23 years ago Closed 18 years ago

modal dialog asking for a floppy/removable media cannot be canceled

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: relnote)

found using 2002.05.06.08-1.0.0 (branch, comm) bits on win2k. 0. make sure you have a floppy disk inserted in your machine's drive. 1. open up the download mgr (Tools > Download Manager). 2. download a file to disk (eg, select "save link target" from the context menu for the banner on this page). 3. after saving is done, quit the app. 4. remove the floppy from the drive. 5. open up the download mgr, and click on any of the files listed. results: get a dlg saying "There is no disk in the drive. Please insert a disk into drive A:" 6. click the Cancel button. results: the dlg appears again. repeat ad nauseum... i cannot access the dl mgr window, or the browser window. i need to use the task manager to quit the app.
workaround: insert a floppy, delete the entries in the dl mgr window, eject floppy. subsequent access to the dl mgr won't display the error dlg.
Keywords: relnote
clarification of workaround: insert floppy remove *all* entries in dl mgr window eject floppy close dl mgr window
QA Contact: sairuh → petersen
Confirming on Mozilla 1.2.1, very annoying.
*** Bug 206962 has been marked as a duplicate of this bug. ***
This also happens when you have a link or an image in a webpage pointing to the floppy. See bug 206962 for instance. It's not related to the download at all, but to the file-handling. So we move this bug to the correct component ?
Confirmed: Mozilla 1.4 RC1, Windows 2000.
*** Bug 221545 has been marked as a duplicate of this bug. ***
Summary: modal dlg asking for a floppy cannot be canceled → modal dialog asking for a floppy cannot be canceled
*** Bug 193353 has been marked as a duplicate of this bug. ***
I just hit this from a web page too - I guess File Handling is a better place, if this is going to cover the issue from bug 206962 as well. Having poked around, it seems like there's no security issue, but having remote sites making the browser access removable drives is annoying.
Assignee: firefox → file-handling
Component: Download Manager → File Handling
QA Contact: chrispetersen → ian
actually, thinking about it, this is not the same bug, and I don't think morphing this is the right thing to do. changing back... apologies for bug spam.
Assignee: file-handling → download-manager
Component: File Handling → Download Manager
QA Contact: ian
*** Bug 252556 has been marked as a duplicate of this bug. ***
I have experienced this bug in FireFox 0.9.3. I am on a Windows XP Professional machine. I know I had been downloading files directly to my floppy drive (drive A:) a night or two ago (by right-clicking and choosing the save file as option), now every time I try and do that same thing (right click, and try and "save file as") before I have the option to choose where to download the file to, it tells me that No Disk is available in A:, after choosing the cancel option, it goes in an infinite loop, similiar to the one described in Bug #249693 (however there is no correlation with MS Excel).
*** Bug 258645 has been marked as a duplicate of this bug. ***
*** Bug 253819 has been marked as a duplicate of this bug. ***
*** Bug 260468 has been marked as a duplicate of this bug. ***
The behavior in Firefox is slightly different. After saving to a removable disk, etc. clicking the cancel button brings up the download manager which allows you to remove the item. Since this is different from the behavior of most other applications on Windows which just ignore that the drive is no longer present this has caused confusion for users. Should this be addressed separately for Firefox? There is also a MozillaZine thread here: http://forums.mozillazine.org/viewtopic.php?t=131601 My user agents: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040923 Firefox/0.10 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040920
*** Bug 261927 has been marked as a duplicate of this bug. ***
*** Bug 265970 has been marked as a duplicate of this bug. ***
*** Bug 270144 has been marked as a duplicate of this bug. ***
*** Bug 262048 has been marked as a duplicate of this bug. ***
More general is Bug 153377 to avoid such dialogs (not only for DM).
Summary: modal dialog asking for a floppy cannot be canceled → modal dialog asking for a floppy/removable media cannot be canceled
*** Bug 249693 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 271337 has been marked as a duplicate of this bug. ***
*** Bug 271215 has been marked as a duplicate of this bug. ***
*** Bug 268558 has been marked as a duplicate of this bug. ***
*** Bug 272845 has been marked as a duplicate of this bug. ***
*** Bug 272942 has been marked as a duplicate of this bug. ***
So many duplicates, so much time has passed - yet we still have no solution for this stupid and annoying bug, or even an indication that someone is investigating it?
*** Bug 273167 has been marked as a duplicate of this bug. ***
*** Bug 278379 has been marked as a duplicate of this bug. ***
*** Bug 279383 has been marked as a duplicate of this bug. ***
Stack from the dialog is at: http://twpol.dyndns.org/temp/stack_2.txt I don't trust stack item 03, but the rest looks good, certainly everything below it is ok. JS function that the code is running right near the top is: chrome://communicator/content/downloadmanager/downloadmanager.js @ line 168
(In reply to comment #32) > Stack from the dialog is at: http://twpol.dyndns.org/temp/stack_2.txt > JS function that the code is running right near the top is: > chrome://communicator/content/downloadmanager/downloadmanager.js @ line 168 Given that we're calling Exists(), I set a breakpoint in Venkman to see what was going on (there's only one place we call Exists), and here's the JS stack: dVC_isCommandEnabled downloadmanager.js:183 isCommandEnabled x-jsd:native-code goUpdateCommand globalOverlay.js:55 dVC_onCommandUpdate downloadmanager.js:343 oncommandupdate downloadmanager.xul:1 updateCommands xjsd:native-code onSelect downloadmanager.js:138 onselect downloadmanager.xul:1 select x-jsd:native-code onRebuild downloadmanager.js:124 The stack didn't appear to change even when I continued a few times. Somebody is checking many times to see whether the "show file location" command should be enabled.
(In reply to comment #33) > Somebody > is checking many times to see whether the "show file location" command should be > enabled. It looks like this "somebody" is checking once for each item in the download manager list - I hit the check only 7 times after deleting all but 7 entries. Unfortunately, I'm experiencing a huge number of crashes while trying to debug this (unrelated problem I'm having). I *think* the function in globalOverlay.js is being called 7 times, but the crashes are making this difficult :(. I was hoping to just use breakpoints in the JS debugger to see what function in the call stack is the first to be called once per download instead of just once, but it looks like I can't do that tonight.
*** Bug 280560 has been marked as a duplicate of this bug. ***
Similar situation(different though) is reported to Bug 240644. (Mail attachment directry, Network resource) Mozilla saved last used download directry in next entry of prefs.js. > user_pref("browser.download.dir", "C:\\TEMP"); So next can be a workaround, although restart of Mozilla is required when problem occured. (1) Add browser.download.dir entry in user.js file in profile directry. user_pref("browser.download.dir", "C:\\TEMP"); (2) Restart Mozilla(whole Mozilla, not Browser only) when problem occured. Note-1: "C:\TEMP" will be always used as candidate of directry when first trial of download/save after restart, because last used directry is forced to "C:\TEMP" on every restart. Note-2: prefs.js entry used for mail attachment is different. user_pref("mail.compose.attach.dir", "C:\\TEMP");
Whiteboard: DUPEME
In addition to workaround in comment #36, changing prefs.js setting by "about:config" while running is also available, if current Mozilla or current Firefox.
Duping to similar, older bug 127386 per Timelesses "DUPEME". Both bugs concern the same message and situation. *** This bug has been marked as a duplicate of 127386 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
unduping per bug 127386 comment 4.
Status: RESOLVED → VERIFIED
Whiteboard: DUPEME
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 127386 has been marked as a duplicate of this bug. ***
DUP'ed Bug 127386 is same problem when Composer.
Is this just a case of having to call ::SetErrorMode(SEM_FAILCRITICALERRORS) sometime during startup, or will that affect the common dialogs too?
that's the thing to do, yes.
Whiteboard: DUPEME
Can next be a workaround when problem on download? - Disable "Open the download manager" option of preference - And use "Save as" etc. instead of direct Download Manager use (ie. "open a progress dialog" or "Don't open anything")
*** Bug 283864 has been marked as a duplicate of this bug. ***
Bug 202735 and Bug 257052 are bugs for similar problem, although product/component is different.
*** Bug 276538 has been marked as a duplicate of this bug. ***
*** Bug 289203 has been marked as a duplicate of this bug. ***
*** Bug 292035 has been marked as a duplicate of this bug. ***
*** Bug 295006 has been marked as a duplicate of this bug. ***
*** Bug 295174 has been marked as a duplicate of this bug. ***
*** Bug 298247 has been marked as a duplicate of this bug. ***
Whiteboard: DUPEME
*** Bug 299386 has been marked as a duplicate of this bug. ***
*** Bug 299810 has been marked as a duplicate of this bug. ***
*** Bug 301218 has been marked as a duplicate of this bug. ***
*** Bug 302856 has been marked as a duplicate of this bug. ***
Would the solution in bug 270557 / bug 303675 have helped ? I mean, would the exits() check return false if the A-drive exists, but no floppy was loaded ?
*** Bug 303919 has been marked as a duplicate of this bug. ***
I can't reproduce this on my system (WinXP SP2).
*** Bug 306973 has been marked as a duplicate of this bug. ***
AFAICT this should be fixed for FF 1.5/SeaMonkey 1.0, see Bug 285497/Bug 153377.
Version: Trunk → 1.7 Branch
*** Bug 309417 has been marked as a duplicate of this bug. ***
This is currently a Seamonkey specific bug. Either it should go somewhere in Core instead (I'm not sure where - I guess it depends how this is fixed), or else the duping of Firefox bugs to this one was incorrect and there should be a separate bug for Firefox.
*** Bug 316193 has been marked as a duplicate of this bug. ***
Bug 303675 was fixed on 2005-08-08, then similar bugs(Bug 202735, Bug 257052) were closed as DUP of Bug 303675. To all problem reporters: Does the problem still remain in latest-trunk?
Yes, the bug still activates when my downloads screen exceeds a number of downloads (using 1.5). Also, since last time my downloads got bugged, my computer detects the floppy drive, however, it doesn't detect the disk inside it.
*** Bug 353439 has been marked as a duplicate of this bug. ***
Changing to Core/File handling.
Component: Download Manager → File Handling
Product: Mozilla Application Suite → Core
Assignee: download-manager → file-handling
Status: REOPENED → NEW
QA Contact: ian
Per duplicate 300383 this can randomly cause a crash. Upgrading.
Severity: normal → critical
Keywords: crash
(In reply to comment #70) > Per duplicate 300383 this can randomly cause a crash. Upgrading. > I don't agree - bug 300382 doesn't describe a crash, but a series of modal dialogs. Annoying, yes, but not a crash.
Jo,you are right, I didn't pay close enough attention to #4 on the dupe.
Severity: critical → major
Keywords: crash
this was fixed for seamonkey trunk last week when suiterunner landed. there are no plans to backport suiterunner and there are no plans to backport the fix. (yes, the fix is trivial, but it's clearly not a high priority.)
Status: NEW → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → WORKSFORME
Version: 1.7 Branch → Trunk
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.