Closed Bug 8483 Opened 27 years ago Closed 27 years ago

Linux & Mac only-POP only-Crash sending a Reply to message with no text

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
Other
IRIX
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: esther, Assigned: rhp)

References

Details

Using 19990618 on Linux and Mac only (POP only),with the Reply bug fix 8464. User will crash if they try to send a message they are replying to. Note: user can't type any text in this reply to message which may be causing the crash. 1. Launch Messenger 2. Select a message 3. Click Reply 4. Start typing where the cursor is. Nothing happens. 5. Move the cursor just in front of the first text that appears on the reply message and start typing. Nothing happens. 6. Click Send, you will crash
Status: NEW → ASSIGNED
Summary: Linux & Mac only-POP only-Crash sending a Reply to message with no text → Linux & Mac only-POP only-Crash sending a Reply to message with no text
Target Milestone: M7
I forget to tell that the new quoting won't work if compose is setup in plain text only (user_pref("mail.identity.id2.send_html", false);), Ender would be totally frozen and you cannot type anything. Are you testing the reply in plain text mode?
I discovered that the new quoted reply doesn't work either if the original message is a multi-parts message. What append is that the HTML generated by the reply is very bad and Ender as a lot of trouble to work with it. Ender will even crash when we send the message. At this point, I think I will deactivate the new quoting and use the old one for every cases. We may not always correctly quoted HTML message but at least we won't crash and the user would always be able to edit it.
I think that's a good idea. In the mail/news newsgroup, Rich said that the new quoting wouldn't be in M7 which is why we hadn't gotten around to testing with the new quoting yet until it was turned on yesterday. Thanks.
When you say "very bad", could you describe what you mean. This is the same HTML that is generated when we display the message, so it can't be that invalid. - rhp
the other solution if you don't want a respin is to set the following prefs to disable the new quoting: user_pref("mail.old_quoting", true); please choose a solution...
Rich, here is the generated html for a non-multipart message sent by lisa to qatest03, it's also wrong: <br><BLOCKQUOTE TYPE=CITE><html><br>--- Original Message ---<br><br><BLOCKQUOTE><table BORDER=0><TR><td>< div align=right><B>Message-ID:</B></div></td><td>&lt;371F86F1.D4CA03CD@netscape.com&gt;</td></TR><TR><td>< div align=right><B>From:</B></div></td><td>lchiang@netscape.com (Lisa Chiang)</td></TR><TR><td><div align=right>< B>To:</B></div></td><td>chris kritzer test3 &lt;qatest03@netscape.com&gt;</td></TR><TR><td><div align=right><B> Subject:</B></div></td><td>Re: trying again</td></TR><TR><td><div align=right><B>References:</B></div></td><td>& lt;003f01be8cf9$9ac527f0$46290cd0@mcom.com&gt;</td></TR></TABLE></BLOCKQUOTE><!doctype html public "-// w3c//dtd html 4.0 transitional//en"> <html> <body bgcolor="#FFFFFF"> Got all your messages. <p>chris kritzer test3 wrote: <blockquote TYPE=CITE><style></style> <font face="Arial"><font size=-1>test</font></font><font face="Arial"><font size=-1>test</font></font><font face= "Arial"><font size=-1>test</font></font><font face="Arial"><font size=-1>tet</font></font></blockquote> <p>-- <br>Lisa Chiang <br>Mail/News Client QA - 5.0 project <br>lchiang@netscape.com <br>&nbsp; </body> </html> </html></BLOCKQUOTE>
...that was generated on Mac with today's build.
QA: If you want to retreive the generated HTML for a reply, Do the reply and you will find it into a temp file named "tempMessage.html" in the temp folder or at the application level (on Mac).
I'm still not following you when you say this is "wrong". Load this into 4.x, viewer.exe, Internet Explorer and it looks fine. Is this perfect HTML, absolutely not, but that is because with MHTML, we wrap HTML coming from who knows where. Unless we want libmime to become an HTML parser (and we don't), things like our display engine and Ender will have to deal with it. If we are holding out to make the HTML perfect coming out of libmime, we'll never ship. I can quote this message and many more complicated messages on Win32 so I think this is a platform parity bug with Ender, not Quoting. - rhp
To respond to JF's comment: If there is going to be another respin, I'd like to take the fix of going back to the old way on all platforms just for M7. If there is not another respin, the release noting is fine for me. Esther verified that the old_quoting pref works on Linux. Peter, can you verify the old_quoting preference on Mac?
I am not an expert in HTML but for me it's look like wrong because It has several tags <HTML> and because It has some data that are part of the body before the <BODY> tag. Ender or Quoting problem, I don't really know who is responsible. In any case something wrong here me need to fix quickly. The best way is to use the old quoting all the time until we figure how to really fix it.
Understood, but turning off quoting is fixing the symptom and not the problem. This is fine for M7, but I just want to make sure that the problem is identified correctly. - rhp
Blocks: 8481
the bug 8481 is a side effect on all platform of this bug.
Using linux (1999-06-18-08 m7), I get the crash problem too. Here is the stack trace: shazam/u/fenella:41 >more crash_trace #0 0x8a2574d in ?? () #1 0x40642baf in nsHTMLEditor::OutputHTMLToString () #2 0x40651b66 in nsEditorShell::GetContentsAsHTML () #3 0x40d911e5 in nsMsgCompose::SendMsg () #4 0x4007d866 in XPTC_InvokeByIndex () #5 0x40c2b3e2 in nsXPCWrappedNativeClass::CallWrappedMethod () #6 0x40c2b850 in WrappedNative_CallMethod () #7 0x4033b00a in js_Invoke () #8 0x40340c6e in js_Interpret () #9 0x4033b058 in js_Invoke () #10 0x40340c6e in js_Interpret () #11 0x4033b058 in js_Invoke () #12 0x4033b1fd in js_CallFunctionValue () #13 0x40326089 in JS_CallFunctionValue () #14 0x402cc90c in nsJSEventListener::HandleEvent () #15 0x4098876d in nsEventListenerManager::HandleEvent () #16 0x4079bbd8 in RDFElementImpl::HandleDOMEvent () #17 0x4098a29c in nsEventStateManager::CheckForAndDispatchClick () #18 0x409897ec in nsEventStateManager::PostHandleEvent () #19 0x409b0d6a in PresShell::HandleEvent () #20 0x40c3759d in nsView::HandleEvent () #21 0x40c3edf9 in nsViewManager::DispatchEvent () #22 0x40c3604e in HandleEvent () #23 0x400b8bc2 in nsWidget::DispatchEvent () #24 0x400b8b19 in nsWidget::DispatchWindowEvent () #25 0x400b8c3f in nsWidget::DispatchMouseEvent () #26 0x400b925b in nsWidget::OnButtonReleaseSignal () #27 0x400b950f in nsWidget::ButtonReleaseSignal () #28 0x80c4014 in gtk_marshal_BOOL__POINTER (object=0x893c8f8, func=0x400b94d8 <nsWidget::ButtonReleaseSignal(_GtkWidget *, _GdkEventButton *, void *)>, func_data=0x893c740, args=0xbffff610) at gtkmarshal. c:32 #29 0x809ce6f in gtk_handlers_run (handlers=0x8918a18, signal=0xbffff5cc, object=0x893c8f8, params=0xbffff610, after=0) at gtksignal.c:1909 #30 0x809c4f6 in gtk_signal_real_emit (object=0x893c8f8, signal_id=21, params=0xbffff610) at gtksignal.c:1469 #31 0x809ac32 in gtk_signal_emit (object=0x893c8f8, signal_id=21) at gtksignal.c:552 #32 0x80bc75c in gtk_widget_event (widget=0x893c8f8, event=0x81b2f8c) at gtkwidget.c:2784 #33 0x8085db1 in gtk_propagate_event (widget=0x893c8f8, event=0x81b2f8c) at gtkmain.c:1295 at gtkmain.c:1295 #34 0x8085352 in gtk_main_do_event (event=0x81b2f8c) at gtkmain.c:752 #35 0x80d3a27 in gdk_event_dispatch (source_data=0x0, current_time=0xbffff958, user_data=0x0) at gdkevents.c:2086 #36 0x80e69ac in g_main_dispatch (current_time=0xbffff958) at gmain.c:647 #37 0x80e6e27 in g_main_iterate (block=1, dispatch=1) at gmain.c:854 #38 0x80e6f41 in g_main_run (loop=0x81b96a8) at gmain.c:912 #39 0x8084e67 in gtk_main () at gtkmain.c:475 #40 0x400ae8ff in nsAppShell::Run () #41 0x4001a51e in nsAppShellService::Run () #42 0x8051c27 in main () (gdb) quit
JF, let's turn off new quoting for M7 and find the real bug (bad HTML from libmime?) in M8. chofmann approved that change at the 4pm mtg.
Status: ASSIGNED → RESOLVED
Closed: 27 years ago
Resolution: --- → FIXED
I have tuned off by default the new quoting who was leading to this crash. The new quoting can still be turn on with the pref: user_pref("mail.old_quoting", false);
Status: RESOLVED → REOPENED
Target Milestone: M7 → M8
Resolution: FIXED → ---
Let's do this - there still is a crash with the new quoting style - let's use this bug to track that crash. I'll mark the target milestone to M8 for now. (so for M7, this crash is bypassed by having the default be to the old quoting style.)
When I try this in my Monday build, with new quoting enabled, I crash with a different stack trace, because the editor's mPresShell is garbage. #0 0x40928c80 in nsEditor::GetPresShell (this=0x8624a90, aPS=0xbfffdc74) at /builds/mon/mozilla/editor/base/nsEditor.cpp:476 #1 0x4095ad08 in nsHTMLEditor::OutputHTMLToString (this=0x8624a90, aOutputString=@0xbfffdcc0) at /builds/mon/mozilla/editor/base/nsHTMLEditor.cpp:701 #2 0x40974abf in nsEditorShell::GetContentsAsHTML (this=0x8622e18, contentsAsHTML=0xbfffddb8) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:1499 #3 0x4128f279 in nsMsgCompose::SendMsg (this=0x861d610, deliverMode=0, callback=0x0) at /builds/mon/mozilla/mailnews/compose/src/nsMsgCompose.cpp:278 #4 0x400a6bd4 in XPTC_InvokeByIndex (that=0x861d610, methodIndex=6, paramCount=2, params=0xbfffe094) at /builds/mon/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:154 [ ... ] (gdb) p *mPresShell $5 = {<nsISupports> = {_vptr. = 0x1}, }
When I try this in my Monday build, with new quoting enabled, I crash with a different stack trace, because the editor's mPresShell is garbage. #0 0x40928c80 in nsEditor::GetPresShell (this=0x8624a90, aPS=0xbfffdc74) at /builds/mon/mozilla/editor/base/nsEditor.cpp:476 #1 0x4095ad08 in nsHTMLEditor::OutputHTMLToString (this=0x8624a90, aOutputString=@0xbfffdcc0) at /builds/mon/mozilla/editor/base/nsHTMLEditor.cpp:701 #2 0x40974abf in nsEditorShell::GetContentsAsHTML (this=0x8622e18, contentsAsHTML=0xbfffddb8) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:1499 #3 0x4128f279 in nsMsgCompose::SendMsg (this=0x861d610, deliverMode=0, callback=0x0) at /builds/mon/mozilla/mailnews/compose/src/nsMsgCompose.cpp:278 #4 0x400a6bd4 in XPTC_InvokeByIndex (that=0x861d610, methodIndex=6, paramCount=2, params=0xbfffe094) at /builds/mon/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:154 [ ... ] (gdb) p *mPresShell $5 = {<nsISupports> = {_vptr. = 0x1}, }
More info: if I set a breakpoint in nsEditor::Init, I see it getting called twice, with different editors; the second time it's being called recursively from service->CreateBundle(url, locale, getter_AddRefs(mStringBundle)) where service is kStringBundleServiceCID. When we eventually crash on send, "this" is a third value, not equal to "this" in either of the two Init calls. The nsEditorShell is the same in all cases. If I turn old quoting back on, I only see the second Init call. I still crash on send, but it's later, in ~nsDocument. The editor pointer at the time of the crash is the same as the one on which Init was called. Here's the stack trace for the recursive call (sorry for the length): #0 nsEditor::Init (this=0x859b4a0, aDoc=0x8592edc, aPresShell=0x84c90e8) at /builds/mon/mozilla/editor/base/nsEditor.cpp:493 #1 0x40938200 in nsTextEditor::Init (this=0x859b4a0, aDoc=0x8592edc, aPresShell=0x84c90e8) at /builds/mon/mozilla/editor/base/nsTextEditor.cpp:239 #2 0x4095883a in nsHTMLEditor::Init (this=0x859b4a0, aDoc=0x8592edc, aPresShell=0x84c90e8) at /builds/mon/mozilla/editor/base/nsHTMLEditor.cpp:122 #3 0x40970d87 in nsEditorShell::InstantiateEditor (this=0x85d8810, aDoc=0x8592edc, aPresShell=0x84c90e8) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:341 #4 0x4097115a in nsEditorShell::DoEditorMode (this=0x85d8810, aWebShell=0x858c270) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:392 #5 0x40971e58 in nsEditorShell::PrepareDocumentForEditing (this=0x85d8810) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:653 #6 0x40977041 in nsEditorShell::OnEndDocumentLoad (this=0x85d8810, loader=0x858c860, aUrl=0x849d648, aStatus=0, aObserver=0x858c284) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:2313 #7 0x402c79f8 in nsWebShell::OnEndDocumentLoad (this=0x858c270, loader=0x858c860, aURL=0x849d648, aStatus=0, aWebShell=0x858c284) at /builds/mon/mozilla/webshell/src/nsWebShell.cpp:2674 #8 0x402bf9eb in nsDocLoaderImpl::FireOnEndDocumentLoad (this=0x858c860, aLoadInitiator=0x858c860, aStatus=0) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:866 #9 0x402bfeeb in nsDocLoaderImpl::LoadURLComplete (this=0x858c860, aURL=0x849d648, aBindInfo=0x849d608, aStatus=0) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:1044 #10 0x402c10fb in nsDocumentBindInfo::OnStopBinding (this=0x849d608, aURL=0x849d648, aStatus=0, aMsg=0xbfffe5b8) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:1609 #11 0x402a686d in stub_abort (stream=0x85cc2b8, status=-1) at /builds/mon/mozilla/network/module/nsStubContext.cpp:816 #12 0x401c3682 in net_ProcessFile (cur_entry=0x849da80) at /builds/mon/mozilla/network/protocol/file/mkfile.c:1372 #13 0x40275ed7 in NET_ProcessNet (ready_fd=0x0, fd_type=1) at /builds/mon/mozilla/network/main/mkgeturl.c:3355 #14 0x4027ddb9 in NET_PollSockets () at /builds/mon/mozilla/network/main/mkselect.c:298 #15 0x402a2cf2 in nsBlockingStream::Read (this=0x848e430, aBuf=0x8499978 "ø\021\207@ø\021\207@L\226@@L\226@@\006", aCount=8192, aReadCount=0xbfffe9a8) at /builds/mon/mozilla/network/module/nsNetStream.cpp:711 #16 0x40072b7c in ByteBufferImpl::Fill (this=0x857fee8, aErrorCode=0xbfffea08, aStream=0x848e430, aKeep=0) at /builds/mon/mozilla/xpcom/ds/nsByteBuffer.cpp:127 #17 0x400929e7 in ConverterInputStream::Fill (this=0x8499950, aErrorCode=0xbfffea08) at /builds/mon/mozilla/xpcom/io/nsUnicharInputStream.cpp:266 #18 0x400928dd in ConverterInputStream::Read (this=0x8499950, aBuf=0xbfffea42, aOffset=0, aCount=1, aReadCount=0xbfffea3c) at /builds/mon/mozilla/xpcom/io/nsUnicharInputStream.cpp:239 #19 0x40079644 in nsPersistentProperties::Read (this=0x848e380) at /builds/mon/mozilla/xpcom/ds/nsProperties.cpp:403 #20 0x40079016 in nsPersistentProperties::Load (this=0x848e380, aIn=0x848e430) at /builds/mon/mozilla/xpcom/ds/nsProperties.cpp:227 #21 0x412fc418 in nsStringBundle::nsStringBundle (this=0x84f4630, aURL=0x848e398, aLocale=0x0, aResult=0xbfffeb68) at /builds/mon/mozilla/intl/strres/src/nsStringBundle.cpp:163 #22 0x412fc9e1 in nsStringBundleService::CreateBundle (this=0x84f4b50, aURL=0x848e398, aLocale=0x0, aResult=0x8581558) at /builds/mon/mozilla/intl/strres/src/nsStringBundle.cpp:234 #23 0x40929130 in nsEditor::Init (this=0x8581538, aDoc=0x8578c74, aPresShell=0x84930e0) at /builds/mon/mozilla/editor/base/nsEditor.cpp:565 #24 0x40938200 in nsTextEditor::Init (this=0x8581538, aDoc=0x8578c74, aPresShell=0x84930e0) at /builds/mon/mozilla/editor/base/nsTextEditor.cpp:239 #25 0x4095883a in nsHTMLEditor::Init (this=0x8581538, aDoc=0x8578c74, aPresShell=0x84930e0) at /builds/mon/mozilla/editor/base/nsHTMLEditor.cpp:122 #26 0x40970d87 in nsEditorShell::InstantiateEditor (this=0x85d8810, aDoc=0x8578c74, aPresShell=0x84930e0) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:341 #27 0x4097115a in nsEditorShell::DoEditorMode (this=0x85d8810, aWebShell=0x858c270) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:392 #28 0x40971e58 in nsEditorShell::PrepareDocumentForEditing (this=0x85d8810) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:653 #29 0x40977041 in nsEditorShell::OnEndDocumentLoad (this=0x85d8810, loader=0x858c860, aUrl=0x858dbd8, aStatus=0, aObserver=0x858c284) at /builds/mon/mozilla/editor/base/nsEditorShell.cpp:2313 #30 0x402c79f8 in nsWebShell::OnEndDocumentLoad (this=0x858c270, loader=0x858c860, aURL=0x858dbd8, aStatus=0, aWebShell=0x858c284) at /builds/mon/mozilla/webshell/src/nsWebShell.cpp:2674 #31 0x402bf9eb in nsDocLoaderImpl::FireOnEndDocumentLoad (this=0x858c860, aLoadInitiator=0x858c860, aStatus=0) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:866 #32 0x402bfeeb in nsDocLoaderImpl::LoadURLComplete (this=0x858c860, aURL=0x858dbd8, aBindInfo=0x85d1fd8, aStatus=0) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:1044 #33 0x402c10fb in nsDocumentBindInfo::OnStopBinding (this=0x85d1fd8, aURL=0x858dbd8, aStatus=0, aMsg=0xbffff014) at /builds/mon/mozilla/webshell/src/nsDocLoader.cpp:1609
Cc'ing cmanske since he put the string bundle stuff in and so maybe knows how it's supposed to work.
Looks like the document loader OnEndDocumentLoad is getting called twice. We should have protection in for that, but I'm surprised that the string bundle stuff causes an extra load.
On Mac, loading the string bundle does not cause OnEndLoadDocument to be called a second time. I think this behaviour might depend on whether NETLIB_THREAD is defined.
Assignee: ducarroz → rhp
Status: REOPENED → NEW
reassign to Rich
There are two problems here. 1. Mailnews are calling LoadURL on the editor shell more than once. We don't currently handle this situation, although we will. 2. Loading string bundles is causing our OnEndDocumentLoad to get called on our doc loader observer, on some platforms. This seems wrong.
Status: NEW → ASSIGNED
Target Milestone: M8 → M9
I don't think this will be an issue anymore because I totally reworked the way quoting was done, but I currently can't start apprunner so I will mark M9 and hopefully close tomorrow. - rhp
Status: ASSIGNED → RESOLVED
Closed: 27 years ago → 27 years ago
Resolution: --- → FIXED
This should have been fixed after the major rework on quoting. - rhp
linux (1999-10-07-08 M11) POP: Replying to a message using HTML or plain text works fine. Unable to check Mac because today's build Mac received message is broken (bug 15720)
Status: RESOLVED → VERIFIED
linux Redhat 6.0 (1999-10-26-08 M11) Mac (1999-10-26-08 M11) Reply to a message using Text editor and HTML editor works fine.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.