Last Comment Bug 12495 - [BLOCKER][REGRESSION][PRINTING] assertion (used to crash) when printing mail
: [BLOCKER][REGRESSION][PRINTING] assertion (used to crash) when printing mail
Status: VERIFIED DUPLICATE of bug 21178
:
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: x86 All
: P3 blocker (vote)
: M13
Assigned To: dcone (gone)
: lchiang
: Jet Villegas (:jet)
Mentors:
: 20255 (view as bug list)
Depends on:
Blocks: 11091
  Show dependency treegraph
 
Reported: 1999-08-25 16:56 PDT by (not reading, please use seth@sspitzer.org instead)
Modified: 1999-12-14 16:53 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
pref.js and mailbox in zip, so anybody can debug (1.02 KB, application/octet-stream)
1999-08-27 10:13 PDT, nhottanscp
no flags Details
windows zip file contains reproducible case by browser (frameset.html). (1.62 KB, application/octet-stream)
1999-11-17 09:57 PST, nhottanscp
no flags Details

Description (not reading, please use seth@sspitzer.org instead) 1999-08-25 16:56:48 PDT
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).
Comment 1 Frank Tang 1999-08-25 17:39:59 PDT
Where is the code which call the CreanteInstance of kCParserCID ?

Reassign this to nhotta. Naoki, let's work together tomorrow for this.
Comment 2 nhottanscp 1999-08-26 11:22:59 PDT
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
Comment 3 nhottanscp 1999-08-27 10:13:59 PDT
Created attachment 1401 [details]
pref.js and mailbox in zip, so anybody can debug
Comment 4 nhottanscp 1999-08-27 10:21:59 PDT
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.
Comment 5 Frank Tang 1999-08-27 12:51:59 PDT
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.
Comment 6 lchiang 1999-09-20 15:45:59 PDT
(target milestone is M11 or M12 - add to mail beta tracking bug)
Comment 7 Frank Tang 1999-10-01 16:05:59 PDT
Mark it as M11 after they change the meaning of M11
Comment 8 Frank Tang 1999-11-03 20:35:59 PST
reassign this to naoki. Naoki, please help to take a look at this.
Comment 9 nhottanscp 1999-11-04 16:51:59 PST
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;
Comment 10 nhottanscp 1999-11-08 11:34:59 PST
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.
Comment 11 nhottanscp 1999-11-17 09:57:59 PST
Created attachment 2914 [details]
windows zip file contains reproducible case by browser (frameset.html).
Comment 12 nhottanscp 1999-11-17 10:03:59 PST
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".
Comment 13 nhottanscp 1999-11-17 10:05:59 PST
Additional info:
Regardless of the assertion, everything was printed fine with any charsets
(ISO-8859-1, Shift_JIS, UTF-8).
Comment 14 nhottanscp 1999-11-23 10:49:59 PST
Reassign to dcone for investigation.
Comment 15 dcone (gone) 1999-11-23 12:40:59 PST
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?
Comment 16 nhottanscp 1999-11-23 13:08:59 PST
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).
Comment 17 dcone (gone) 1999-11-29 15:00:59 PST
*** Bug 20255 has been marked as a duplicate of this bug. ***
Comment 18 Karen Huang 1999-12-09 15:01:59 PST
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.
Comment 19 lchiang 1999-12-10 14:23:59 PST
see also bug 21178.  Perhaps this can be closed now and use 21178 to track the
crash on printing on linux?
Comment 20 dcone (gone) 1999-12-10 14:43:59 PST
Track as per the other crashing bug on Linux.

*** This bug has been marked as a duplicate of 21178 ***
Comment 21 lchiang 1999-12-14 16:53:59 PST
verified as duplicate.

Note You need to log in before you can comment on or make changes to this bug.