12495 - [BLOCKER][REGRESSION][PRINTING] assertion (used to crash) when printing mail

Status: VERIFIED DUPLICATE of bug 21178

(Core :: Printing: Output, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

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]

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]

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]

Attachment: pref.js and mailbox in zip, so anybody can debug

Comment 4

[nhottanscp]

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 [e-mail] for question about the set up.

Comment 5

[Frank Tang]

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]

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

Comment 7

[Frank Tang]

Mark it as M11 after they change the meaning of M11

Comment 8

[Frank Tang]

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

Comment 9

[nhottanscp]

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]

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]

Attachment: windows zip file contains reproducible case by browser (frameset.html).

Comment 12

[nhottanscp]

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 [e-mail] to cc. Change product to "Browser".

Comment 13

[nhottanscp]

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

Comment 14

[nhottanscp]

Reassign to dcone for investigation.

Comment 15

[dcone (gone)]

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]

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

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

Comment 18

[Karen Huang]

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]

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

Track as per the other crashing bug on Linux.

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

Comment 21

[lchiang]

verified as duplicate.

Comment 22

[Intermittent Failures Robot]

1 failures in 4289 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• fenix: 1

Platform breakdown:

• gecko-decision: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=12495&startday=2020-07-27&endday=2020-08-02&tree=all