http://www.nps.gov/muwo/home.htm contains an image reference to "file:///A|/images/pix-invs.gif". When loading the page Mozilla attempts to retrieve the image and if the A: drive is empty brings up a dialog to say so, which has to be dismissed to continue loading. I know there is already bug 69070, duped to bug 7266, on the general issue of image references to local files, but when the local file is on a removable disk it is much worse from a UE point of view. There is a potential DOS attack here, and disallowing it as a special case won't have the unwanted side effects for Composer that I understand are blocking the general case. IE attempts to access the floppy (the light goes on and I hear the drive motor) and then continues to load the page without reporting an error. Opera seems to ignore the <img> completely.

I agree, we should not prompt the user in this case. The fix for that would probably be in necko, or the image code.

IMHO Bug 153377 could be resolved as dupe of this. But please change the summary to include all removable drives and the no disk popup/dialog. See Bug 153377 comment 19.

As far as I know, on Windows, the OS is what puts up that silly dialog. If we try to access the disk at all, we can't stop it coming up. So this is just a dup of bug 69070, imo.

Well, as I said in comment 0, IE seems to manage it somehow ;-)

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/getvolumeinformation.asp Remarks If you are attempting to obtain information about a floppy drive that does not have a floppy disk or a CD-ROM drive that does not have a compact disc, the system displays a message box asking the user to insert a floppy disk or a compact disc, respectively. To prevent the system from displaying this message box, call the SetErrorMode function with SEM_FAILCRITICALERRORS.

The reference timeless cited in comment 6 is the right solution.

a few things in no particular order: 1. i'd like to protest the resolution of a perfectly good bug which had a stack trace against a new and utterly useless bug which had nothing. 2. SetErrorMode <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/seterrormode.asp> is per application, not thread. so while we could use the patch I'm about to post, it will eventually break. "Because the error mode is set for the entire process, you must ensure that multi-threaded applications do not set different error-mode flags. Doing so can lead to inconsistent error handling." 3. The bug that was duped was about chrome code. Whereas the summary of this bug is clearly about remote content loading local images. 4. Ignoring the above, afaik all instances of the problem from Bug 153377 (FindFirstFile) seem to reside in a few places: nspr xpinstall (a fork of xpinstall, because one xpinstall just wasn't enough) printing (*cough*) eudora import for windows (because writing portable code just isn't worth anyone's effort) nss plugins ok. that's a few more than i want to fix. but it could be worse. and perhaps i can get a few of them to just go away. anyway, i'm going to post a patch for nspr but i think the right fix is for something, at some init time, to call SetErrorMode *once* before threads are created and for no one else to ever call it again for the life of the app. Anyway. I'm annoyed. This bug dies. People who care can go find the bugs I'm actually going to use to post patches. *** This bug has been marked as a duplicate of 69070 ***

Not a dupe of 69070 for reasons already adequately explained. I agree that bug 153377 shouldn't have been duped to this, but I don't see the point in tit-for-tat duping.

Well, then at least post a stack trace.

I don't get how one of these is not the dupe of the other.

What's up with the removed dependencies? BugsThisDependsOn 69070, OtherBugsDependingOnThis 153377

ostgote@gmx.net: this is an open source bug tracking system. you're expected to to read the bugs before you ask questions about them. these bugs are not dependent on eachother and therefore the dependencies have been removed.

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

I had thought that bug 69070 would have fixed this, but no. Stack trace: _PR_MD_GETFILEINFO64(const char * 0x039f3308, PRFileInfo64 * 0x039f4cf0) line 784 PR_GetFileInfo64(const char * 0x039f3308, PRFileInfo64 * 0x039f4cf0) line 528 + 13 bytes nsLocalFile::ResolveAndStat() line 521 + 17 bytes nsLocalFile::GetLastModifiedTime(nsLocalFile * const 0x039f4cc0, __int64 * 0x0012ed0c) line 1432 + 8 bytes imgCache::Get(nsIURI * 0x039f72c0, int * 0x0012efb4, imgRequest * * 0x0012f020, nsICacheEntryDescriptor * * 0x0012efa8) line 270 + 36 bytes imgLoader::LoadImage(imgLoader * const 0x00c0a7f0, nsIURI * 0x039f72c0, nsIURI * 0x03a23548, nsIURI * 0x03a23548, nsILoadGroup * 0x0384aff0, imgIDecoderObserver * 0x039f7164, nsISupports * 0x039cd680, unsigned int 0x00000000, nsISupports * 0x00000000, imgIRequest * 0x00000000, imgIRequest * * 0x039f7168) line 300 + 50 bytes nsContentUtils::LoadImage(nsIURI * 0x039f72c0, nsIDocument * 0x039cd680, nsIURI * 0x03a23548, imgIDecoderObserver * 0x039f7164, int 0x00000000, imgIRequest * * 0x039f7168) line 1768 + 58 bytes nsImageLoadingContent::ImageURIChanged(const nsACString & {...}) line 478 + 69 bytes nsImageLoadingContent::ImageURIChanged(nsImageLoadingContent * const 0x039f7164, const nsAString & {...}) line 411 + 21 bytes nsHTMLImageElement::SetParent(nsIContent * 0x039f7d00) line 634 nsGenericElement::AppendChildTo(nsIContent * 0x039f7148, int 0x00000000, int 0x00000000) line 2600 SinkContext::AddLeaf(nsIHTMLContent * 0x039f7148) line 1565 SinkContext::AddLeaf(const nsIParserNode & {...}) line 1497 HTMLContentSink::AddLeaf(HTMLContentSink * const 0x0378b170, const nsIParserNode & {...}) line 3125 + 18 bytes CNavDTD::AddLeaf(const nsIParserNode * 0x03666080) line 3760 + 25 bytes CNavDTD::HandleDefaultStartToken(CToken * 0x03a103f0, nsHTMLTag eHTMLTag_img, nsCParserNode * 0x03666080) line 1432 + 12 bytes CNavDTD::HandleStartToken(CToken * 0x03a103f0) line 1807 + 20 bytes CNavDTD::HandleToken(CNavDTD * const 0x039c8fe0, CToken * 0x03a103f0, nsIParser * 0x03a12b28) line 992 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x039c8fe0, nsIParser * 0x03a12b28, nsITokenizer * 0x03937598, nsITokenObserver * 0x00000000, nsIContentSink * 0x0378b170) line 471 + 20 bytes nsParser::BuildModel(nsParser * const 0x03a12b28) line 2027 + 34 bytes nsParser::ResumeParse(int 0x00000001, int 0x00000000, int 0x00000001) line 1894 + 12 bytes nsParser::OnDataAvailable(nsParser * const 0x03a12b2c, nsIRequest * 0x0391df88, nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80, unsigned int 0x00000000, unsigned int 0x00000066) line 2572 + 21 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x039992f8, nsIRequest * 0x0391df88, nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80, unsigned int 0x00000000, unsigned int 0x00000066) line 342 + 46 bytes nsFileChannel::OnDataAvailable(nsFileChannel * const 0x0391df90, nsIRequest * 0x0321bce0, nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80, unsigned int 0x00000000, unsigned int 0x00000066) line 556 nsInputStreamPump::OnStateTransfer() line 435 + 70 bytes nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x0321bce4, nsIAsyncInputStream * 0x03a4ce80) line 338 + 11 bytes nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03564874) line 119 PL_HandleEvent(PLEvent * 0x03564874) line 692 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c9bbd8) line 627 + 9 bytes nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x00c9ebe8) line 394 + 12 bytes nsWindow::DispatchPendingEvents() line 3721 nsWindow::ProcessMessage(unsigned int 0x00000101, unsigned int 0x00000074, long 0xc03f0001, long * 0x0012fc4c) line 3932 nsWindow::WindowProc(HWND__ * 0x01d20772, unsigned int 0x00000101, unsigned int 0x00000074, long 0xc03f0001) line 1355 + 27 bytes USER32! 77d43a50() USER32! 77d43b1f() USER32! 77d43d79() USER32! 77d43ddf() nsAppStartup::Run(nsAppStartup * const 0x00c1fc90) line 221 main1(int 0x00000001, char * * 0x002a4448, nsISupports * 0x00b526c0) line 1321 + 32 bytes main(int 0x00000001, char * * 0x002a4448) line 1799 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e8

Oops, my mistake, it is fixed. *** This bug has been marked as a duplicate of 69070 ***