91803 - Clicking on an HTML attachment file leads to a crash

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[Katsuhiko Momoi]

** Observed with 7/21/2001 Win32 build **

To see this crash, you need to follow the instructions in Bug 92793.

1. I have my Navigator start-up page set to:

   http://home.netscape.com/ja

2. I sent myself a short message with HTML attachments.
    File A is 33KB in size.
    File B is 2 KB in size.

3. Received this file on an IMAP server and displays it.
   I see the 2 HTML files inline in the msg view window.

4. I double-click on File A. It opens OK in a new window.

** But sometimes it crashes instead. This is particularly true
   when the problem in steps 5 and 6 don't occur.

5. I double-click on File B. It opens the Navigator Home page set in
   step 1.
6. If step 5 does not lead to this problem, close the new window
   where the attachment is displayed and try again.

File A is here:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=43156

File B is here:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=43157

Comment 1

[Katsuhiko Momoi]

Putting in the 'crash' keyword.

Comment 2

[Katsuhiko Momoi]

I had sent several Talkback reports. They all look the same. Here's
one of the stack traces:

====================================

Incident ID 33183955
Stack Signature nsDocument::SetDocumentCharacterSet 28a34902
Bug ID
Trigger Time 2001-07-21 20:46:13
User Comments 7/21/2001 Win32 build. Clicking an HTML attachment leads to this
crash. 3rd time.
Build ID 2001072106
Product ID Netscape6.10
Platform ID Win32
Stack Trace
nsDocument::SetDocumentCharacterSet
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 848]
HTMLContentSink::SetDocumentCharset
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 5150]
nsParser::SetSinkCharset
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 555]
ParserWriteFunc [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2612]
nsPipe::nsPipeInputStream::ReadSegments
[d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 412]
nsParser::OnDataAvailable
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2688]
nsDocumentOpenInfo::OnDataAvailable
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 236]
nsMimeBaseEmitter::Complete
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeBaseEmitter.cpp,
line 866]
nsStreamConverter::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp, line 1005]
nsImapCacheStreamListener::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 6810]
nsStorageTransport::nsReadRequest::Process
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStorageTransport.cpp, line 504]
nsStorageTransport::nsReadRequest::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStorageTransport.cpp, line 634]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 139]
EventHandler [d:\builds\seamonkey\mozilla\xpcom\proxy\src\nsProxyEvent.cpp, line
510]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 426]
netscp6.exe + 0x16f0 (0x004016f0)
netscp6.exe + 0x11b8 (0x004011b8)
netscp6.exe + 0x3243 (0x00403243)
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

====================================

Comment 3

[Katsuhiko Momoi]

I should have added the following info.

1. My default Mail Viewing encoding is set to:

   Japanese (ISO-2022-JP)

2. The "View | Character Coding | auto-detect" is set to Japanese.

Comment 4

[Håkan Waara]

I can't for my life reproduce this crash with the attachments you used. I tried
doing what you say, many times, no crash.

Comment 5

[selmer (gone)]

Jay,Shiva, does this stack show up in talkback for lots of people?

Comment 6

[Scott MacGregor]

No, according to talkback, Kat's the only person to run into this crash. It's
not a top crasher. He's 5 talkback reports are the only reported incidents of
this crash. 

This bug should probably be re-assigned to I18N. 

Comment 7

[Katsuhiko Momoi]

I should add that there is an interesting correlation between
this bug and Bug 92793. As you see for this bug, we use exactly the
same test files for the 2 attachments. In Bug 92793, the bug was that
double-clicking on one of the files (File B) would open the Browser 
Home Page.
Before this problem begins to happen, however, double-clicking on 
File B opens File B correctly. 

Here's what I found interesting.

** When double-clicking on File B in Bug 92793 opens to the 
   Browser Home Page, i.e. when the problem in Bug 92793 exists, 
   the crash reported for File A in this bug report does NOT occur.

** But when double-clicking on File B opens to the correct page,
   the crash reported in this bug for File A DOES occur.

Comment 8

[Katsuhiko Momoi]

I am sorry. Whenever I said Bug 92793 in this report, I really meant
Bug 91793. 

Comment 9

[nhottanscp]

cc to IQA, could you reproduce this?

Comment 10

[ji]

With today's branch build (07/23), I can't reproduce the problem on my Win98-J.
Clicking on the 1st attachment doesn't cause a crash. Clicking on the 2nd 
attachment doesn't open browser's start-up page. I have global default view 
encoding set to iso-2022-jp and auto-detect is on Japanese. Since bug 91793 has 
been resolved as fixed, could it be that the crash is fixed by the same 
check-in?

Comment 11

[nhottanscp]

I cannot reproduce using today's branch build on Windows 2000 US.
I tried two cases, text/plain and text/html with "File A" attached.
Momoi san, could you attach the message with the crasher? It might be something 
special in your data.

I look at nsDocument::SetDocumentCharacterSet with Frank Tang.
We are not sure where it's exactly crashing but we could do a null check at line 
833.

826 NS_IMETHODIMP nsDocument::SetDocumentCharacterSet(const nsAReadableString& 
aCharSetID)
827 {
828 if (!mCharacterSet.Equals(aCharSetID)) {
829 mCharacterSet = aCharSetID;
830 PRInt32 n = mCharSetObservers.Count();
831 for (PRInt32 i = 0; i < n; i++) {
832 nsIObserver* observer = (nsIObserver*) mCharSetObservers.ElementAt(i);
833 observer->Observe((nsIDocument*) this, NS_LITERAL_STRING("charset").get(),
834 PromiseFlatString(aCharSetID).get());
835 }
836 }
837 return NS_OK;
838 }

Comment 12

[Katsuhiko Momoi]

I have been using today's branch build and 
the test message for a few hours now. I no longer
see this problem with it. I don see the problem
with yesterday's build and so apparently the fix 
for Bug 91793 also fixed this problem.

I am going to mark this resolved as fixed. I also marked the 
dependency on Bug 91793.

Comment 13

[fenella]

Since the reporter already re-tested this bug. Mark it verified.