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

VERIFIED DUPLICATE of bug 21178

Status

()

Core
Printing: Output
P3
blocker
VERIFIED DUPLICATE of bug 21178
18 years ago
7 months ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: dcone (gone))

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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

Updated

18 years ago
Assignee: ftang → nhotta

Comment 1

18 years ago
Where is the code which call the CreanteInstance of kCParserCID ?

Reassign this to nhotta. Naoki, let's work together tomorrow for this.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M10

Comment 2

18 years ago
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

18 years ago
Created attachment 1401 [details]
pref.js and mailbox in zip, so anybody can debug

Updated

18 years ago
Assignee: nhotta → ftang
Status: ASSIGNED → NEW

Comment 4

18 years ago
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.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M10 → M12

Comment 5

18 years ago
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.

Updated

18 years ago
Blocks: 11091

Comment 6

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

Updated

18 years ago
Target Milestone: M12 → M11

Comment 7

18 years ago
Mark it as M11 after they change the meaning of M11

Updated

18 years ago
Target Milestone: M11 → M12

Updated

18 years ago
Assignee: ftang → nhotta
Status: ASSIGNED → NEW

Comment 8

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

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 9

18 years ago
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

18 years ago
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.

Updated

18 years ago
Blocks: 18951

Comment 11

18 years ago
Created attachment 2914 [details]
windows zip file contains reproducible case by browser (frameset.html).

Updated

18 years ago
Product: MailNews → Browser

Comment 12

18 years ago
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

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

Updated

18 years ago
Assignee: nhotta → dcone
Status: ASSIGNED → NEW

Comment 14

18 years ago
Reassign to dcone for investigation.
(Assignee)

Comment 15

18 years ago
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

18 years ago
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).

Updated

18 years ago
Blocks: 20203
(Assignee)

Comment 17

18 years ago
*** Bug 20255 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M13

Updated

18 years ago
Severity: normal → blocker
Summary: [PRINTING] assertion (used to crash) when printing mail → [BLOCKER][REGRESSION][PRINTING] assertion (used to crash) when printing mail

Comment 18

18 years ago
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

18 years ago
see also bug 21178.  Perhaps this can be closed now and use 21178 to track the
crash on printing on linux?
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 20

18 years ago
Track as per the other crashing bug on Linux.

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

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 21

18 years ago
verified as duplicate.

Updated

17 years ago
No longer blocks: 18951

Updated

17 years ago
No longer blocks: 20203
You need to log in before you can comment on or make changes to this bug.