27729 - attempting to open .bmp image crashes Seamonkey

Status: VERIFIED DUPLICATE of bug 38960

(Core :: Networking, defect, P1)

Description

[ekrock's old account (dead)]

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.

Comment 1

[ekrock's old account (dead)]

Attachment: bmp file that crashes Seamonkey when opened

Comment 2

[Eli Goldberg]

Err...this isn't an ImageLib bug.

Pam, should this go to Don, or do you have better ideas?

Thanks.

Comment 3

[pnunn]

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

Comment 4

[pnunn]

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.

Comment 5

[Bill Law]

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).

Comment 6

[don]

Change component and move to M15.

Comment 7

[don]

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

Comment 8

[Sean Richardson]

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.

Comment 9

[Claudius Gayle]

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

Comment 10

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 11

[Bill Law]

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.

Comment 12

[Bill Law]

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

Comment 13

[Judson Valeski]

maybe related to 38960

Comment 14

[Gagan]

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

Comment 15

[Tom Everingham]

verified DUP of 38960

Comment 16

[Bill Law]

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.