here's the stack track for the crash. Note, the crash is now an assert: #0 0x4048c5b5 in nsObserverBase::NotifyWebShell (this=0x80d0440, aDocumentID=160530056, charset=0x98e3fd0 "UTF-8", source=kCharsetFromMetaTag) at nsObserverBase.cpp:52 #1 0x4048de6d in nsMetaCharsetObserver::Notify (this=0x80d0438, aDocumentID=160530056, numOfAttributes=4, nameArray=0xbffff39c, valueArray=0xbffff2d4) at nsMetaCharsetObserver.cpp:272 #2 0x4048d8df in nsMetaCharsetObserver::Notify (this=0x80d0438, aDocumentID=160530056, aTag=0xbffff1bc, numOfAttributes=4, nameArray=0xbffff39c, valueArray=0xbffff2d4) at nsMetaCharsetObserver.cpp:154 #3 0x4054fd0e in nsObserverNotifier::operator() (this=0xbffff180, anObject=0x80d0438) at nsDTDUtils.h:275 #4 0x401189d6 in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libxpcom.so #5 0x405118eb in CNavDTD::WillHandleStartTag (this=0x98e3510, aToken=0x82a3a18, aTag=eHTMLTag_meta, aNode=@0x98e3b08) at CNavDTD.cpp:1119 #6 0x40512168 in CNavDTD::HandleStartToken (this=0x98e3510, aToken=0x82a3a18) at CNavDTD.cpp:1276 #7 0x4050f93d in NavDispatchTokenHandler (aToken=0x82a3a18, aDTD=0x98e3510) at CNavDTD.cpp:241 #8 0x405218b4 in CTokenHandler::operator() (this=0x982d960, aToken=0x82a3a18, aDTD=0x98e3510) at nsTokenHandler.cpp:80 #9 0x40510a50 in CNavDTD::HandleToken (this=0x98e3510, aToken=0x82a3a18, aParser=0x9916fc0) at CNavDTD.cpp:734 #10 0x4051046e in CNavDTD::BuildModel (this=0x98e3510, aParser=0x9916fc0, aTokenizer=0x9917218, anObserver=0x0, aSink=0x98dcb98) at CNavDTD.cpp:551 #11 0x4051eb9c in nsParser::BuildModel (this=0x9916fc0) at nsParser.cpp:941 #12 0x4051ea4c in nsParser::ResumeParse (this=0x9916fc0, aDefaultDTD=0x0, aIsFinalChunk=0) at nsParser.cpp:886 #13 0x4051f059 in nsParser::OnDataAvailable (this=0x9916fc0, channel=0x9917b88, aContext=0x0, pIStream=0x9917c98, sourceOffset=0, aLength=487) at nsParser.cpp:1161 #14 0x40b18492 in nsDocumentBindInfo::OnDataAvailable (this=0x9917a40, channel=0x9917b88, ctxt=0x0, aStream=0x9917c98, sourceOffset=0, aLength=487) at nsDocLoader.cpp:2053 #15 0x409c59f7 in nsOnDataAvailableEvent::HandleEvent (this=0x41d4d0d8) at nsAsyncStreamListener.cpp:344 #16 0x409c5253 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x41d4d0d8) at nsAsyncStreamListener.cpp:144 #17 0x4018029b in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libplds3.so #18 0x401801ac in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libplds3.so #19 0x401493ad in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libxpcom.so #20 0x404bacee in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libwidget_gtk.so #21 0x40692789 in ?? () from /usr/lib/libgdk-1.2.so.0 #22 0x406bed6a in ?? () from /usr/lib/libglib-1.2.so.0 #23 0x406c02c6 in ?? () from /usr/lib/libglib-1.2.so.0 #24 0x406c0801 in ?? () from /usr/lib/libglib-1.2.so.0 #25 0x406c0979 in ?? () from /usr/lib/libglib-1.2.so.0 #26 0x405eff3a in ?? () from /usr/lib/libgtk-1.2.so.0 #27 0x404bb4c9 in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libwidget_gtk.so #28 0x40382491 in ?? () from /builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libnsappshell.so #29 0x804a8b5 in main1 (argc=1, argv=0xbffffa04) at nsAppRunner.cpp:764 #30 0x804aa6f in main (argc=1, argv=0xbffffa04) at nsAppRunner.cpp:831 #31 0x4027fcb3 in ?? () from /lib/libc.so.6 from nsObserverBase.cpp, approx line 52 docLoader->GetContentViewerContainer(aDocumentID,&cvc)) returns NS_OK, but cvc is nsnull; this used to cause a crash but I checked in this patch Index: chardet/src/nsObserverBase.cpp =================================================================== RCS file: /cvsroot/mozilla/intl/chardet/src/nsObserverBase.cpp,v retrieving revision 1.2 diff -p -r1.2 nsObserverBase.cpp *** nsObserverBase.cpp 1999/07/16 11:13:47 1.2 --- nsObserverBase.cpp 1999/08/25 23:52:37 *************** NS_IMETHODIMP nsObserverBase::NotifyWebS *** 49,56 **** --- 49,67 ---- if(NS_FAILED(rv =docLoader->GetContentViewerContainer(aDocumentID, &cvc))) goto done; + /* sspitzer: this was necessary to get printing of mail to work (sort of) + */ + NS_ASSERTION(cvc,"GetContentViewerContainer didn't fail, but cvc is null"); + if (!cvc) { + goto done; + } + if(NS_FAILED( rv = cvc->QueryInterface(kIWebShellServicesIID, (void**)&wss) )) goto done; + + if (!wss) { + goto done; + } #ifndef DONT_INFORM_WEBSHELL // ask the webshellservice to load the URL now print mail works. (not perfectly, though, more bugs to come.) to reproduce the assertion, start up Messenger 5.0, select a folder or newsgroup, select a message, and do "File | Print" I think the crash (now an assert) may be caused by the reloading that goes on when displaying a mail / news message (in order to get the char set correctly).

Where is the code which call the CreanteInstance of kCParserCID ? Reassign this to nhotta. Naoki, let's work together tomorrow for this.

Reproducable on my machine. I am going to debug with Frank. At point of the crash, charset is "UTF-8" and charset source is "kCharsetFromMetaTag". The values are set in messenger, http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#73 7

Reassigning to Frank, I don't have knowleage of META handling. Assign appropiate mile stone. The bug is reproducable by using the attached file. 1) unzip the file and replace the current prefs.js. 2) copy Smoketest to "Mail" directory in the profile directory. 3) edit prefs.js if necessary (only possible change is the path to "Mail" directory). 4) launch mozilla then invoke messenger by menu "Tasks" -> "messenger" Mail to nhotta@netscape.com for question about the set up.

Somehow I have problem to print in browser on Window so it is difficult to compare with mail printing now. It is very strang. When we print mail, we load with ISO-8859-1 (which is wrong) and hit the if(null ) statement so we never reload with UTF-8 (which is correct). Howerver, it print the Japanese correctly to the paper which confuse me a lot. Dcone: in the current design, do we repaser the document when we print ? or we just fetch the same DOM tree and pass it to different presentation shell.

(target milestone is M11 or M12 - add to mail beta tracking bug)

Mark it as M11 after they change the meaning of M11

reassign this to naoki. Naoki, please help to take a look at this.

nsMimeXULEmitter.cpp creates UTF-8 META charset tag which is not needed. Removing that solve this problem. Here is a diff, reviewed by rhp. Index: nsMimeXULEmitter.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/emitters/src/nsMimeXULEmitter.cpp,v retrieving revision 1.40 diff -c -r1.40 nsMimeXULEmitter.cpp *** nsMimeXULEmitter.cpp 1999/10/29 02:17:10 1.40 --- nsMimeXULEmitter.cpp 1999/11/05 00:31:57 *************** *** 176,184 **** { mBody.Append("<HTML>"); ! mBody.Append("<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset="); ! mBody.Append(outCharset); ! mBody.Append("\">"); mBodyStarted = PR_TRUE; return NS_OK; --- 176,184 ---- { mBody.Append("<HTML>"); ! // mBody.Append("<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset="); ! // mBody.Append(outCharset); ! // mBody.Append("\">"); mBodyStarted = PR_TRUE; return NS_OK;

The patch I posted works because charset UTF-8 was specified by messenger to webshell in other place (so it worked even META was not specified in here). But when I tried printing a mail with an attachment of HTML with UTF-8 META, it got the same assertion. So we cannot use the patch to work around of the real META reloding problem.

This is a generic frame prinitng problem (I put a reproducible date as an zip file). The frame set contains three frames with different charsets (ISO-8859-1, Shift_JIS, UTF-8). Hit the asserts for Shift_JIS and UTF-8 but not ISO-8859-1. Also found that printing the same files on the net doesn't have this problem (http://people.netscape.com/nhotta/frame/frameset.html). Adding dcone@netscape.com to cc. Change product to "Browser".

Additional info: Regardless of the assertion, everything was printed fine with any charsets (ISO-8859-1, Shift_JIS, UTF-8).

Reassign to dcone for investigation.

This is a duplicate if it is a frameset printing problem... Anything that uses a Webshell that is embeded in the document will crash.. Can the HTML that crashes this print job be captured and isolated?

Yes, this is a frameset printing problem. This is reproducible with the attached html as well as by printing any mail by messenger. It does not crash, only hits the assertion (used to crash but change to assert and abort the webshell notification).

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

Crash for today's Linux build 12-09-10-M12 when trying to print the mail message. The talkback# are: 2132558,2132559 (but don't know why the report is empty/blank) Change the severity to blocker and put regression on this bug.

see also bug 21178. Perhaps this can be closed now and use 21178 to track the crash on printing on linux?

Track as per the other crashing bug on Linux. *** This bug has been marked as a duplicate of 21178 ***

verified as duplicate.