Using 2000021008 on WinNT 4.0 SP4. To repro: 1) File-->Open 2) using the dialog, select on disk the image I'll attach to this bug report 3) Seamonkey crashes Now granted, .bmp is not a supported image file format for Gecko. (See bug 18502.) However, opening a .bmp file (or any file we don't support, for that matter) should not crash Seamonkey.

Err...this isn't an ImageLib bug. Pam, should this go to Don, or do you have better ideas? Thanks.

Eric: This doesn't look like a problem with the bmp file. I can attempt to view an html file with a bmp on it and it fails to display the bmp gracefully. I can view a bmp from a file list on a web server with no problem. The crash seems to be related to the file open dialog. I'll see how far I can trace it. I'll reassign as necessary. -P

Bill: I'm guessing this bug goes to you. I can only get the error to happen when I do an 'open file' rather than clicking on a file list from a directory on a web server. I see this output message when I see the error: WEBSHELL+ = 10 Lost focus. nsWebShellWindow::GOTFOCUS Got focus. WEBSHELL- = 9 ************************************************************ ** NOTE: This report will only be printed in DEBUG builds.** * Call to xpconnect wrapped JSObject produced this error: * [Exception... "[JS Error: "TypeError: elem.childNodes[0] has no properties" {fil e: "chrome://global/content/downloadProgress.js" line: 67}] [nsIObserver::Observ e]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" locati on: "<unknown>" data: yes] ************************************************************ e:\graptor\mozilla\mozilla\xpfe\components\xfer\src\nsStreamXferOp.cpp 302: Obse rve failed, rv=0x80570021 Lost focus.

Looks like a shortcoming in the JS error handling code. We'll get to it someday (might move to M15 if it's at all hard).

Change component and move to M15.

This can wait until M16 if it's still an issue ...

This looks like it is quite possibly a DUP of bug 34295, "[need review]Unknown Content XUL Dialog asserts to death", FIXED, bug 29858, "File type of */* crashes Mozilla.", or one of the earlier Unknown-Content-Type-Dialog-Crashes... for some reason, these keep coming back, and each time cause a variety of new reports. In any case, using the 2000-04-12-10-M16 and 2000-04-12-05-M15 nightly binaries on WinNT, an Unknown Content Type dialog for "application/octet-stream" comes up, which is what could be expected given the "later..." response to RFE bug 18502, ".BMP images not displayed in Mozilla". No crash.

based on the last comment this sounds like a WFM, eli?

Putting on [nsbeta2+] radar for beta2 fix.

Loading unknown content via file: URLs seems to be completely broken. I get a (sometimes new) empty window and the throbber/progress-meter never indicate load complete. I get the same broken behavior (not as described here, BTW) if I enter c:\some.bmp. Loading image/bmp via http works OK (unknown content handler gets control) so I don't think there's a problem there. I'm going to punt this one over to Necko.

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

maybe related to 38960

*** This bug has been marked as a duplicate of 38960 ***

verified DUP of 38960

Please note: I don't think this was really a dup of 38960. image/bmp content is now handled properly, though, so we can leave this resolved.