9495 - Assert and bad behaviour with colored text in editor

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Syd Logan]

Not sure if this is an editor or HTML bug.

Type in colored text, it shows in the editor o.k.. When trying to get the HTML
content from JS (perhaps anywhere), I get an exception:

NTDLL! 77f76274()
nsDebug::NotReached(const char * 0x017002c4, const char * 0x01700280, int 829)
line 186 + 13 bytes
nsGenericHTMLElement::GetAttribute(int 3, nsIAtom * 0x018aca90, nsString &
{...}) line 829 + 21 bytes
nsGenericHTMLContainerElement::BeginConvertToXIF(nsXIFConverter & {...}) line
2551
nsHTMLFontElement::BeginConvertToXIF(const nsHTMLFontElement * const 0x02d0fc0c,
nsXIFConverter & {...}) line 72 + 18 bytes
nsDocument::BeginConvertToXIF(nsXIFConverter & {...}, nsIDOMNode * 0x02d0fc00)
line 2569
nsMarkupDocument::ToXIF(nsXIFConverter & {...}, nsIDOMNode * 0x02d0fc00) line
287
nsDocument::ConvertChildrenToXIF(nsXIFConverter & {...}, nsIDOMNode *
0x02c46ab0) line 2586
nsMarkupDocument::ToXIF(nsXIFConverter & {...}, nsIDOMNode * 0x02c46ab0) line
288
nsDocument::ConvertChildrenToXIF(nsXIFConverter & {...}, nsIDOMNode *
0x02cedd50) line 2586
nsMarkupDocument::ToXIF(nsXIFConverter & {...}, nsIDOMNode * 0x02cedd50) line
288
nsDocument::CreateXIF(nsString & {...}, nsIDOMSelection * 0x00000000) line 2665
nsMarkupDocument::CreateXIF(nsString & {...}, nsIDOMSelection * 0x00000000) line
296
nsHTMLEncoder::EncodeToString(nsHTMLEncoder * const 0x02d11080, nsString &
{...}) line 181
nsTextEditor::OutputHTMLToString(nsTextEditor * const 0x02cc2294, nsString &
{...}, int 0) line 1630 + 27 bytes
nsHTMLEditor::OutputHTMLToString(nsHTMLEditor * const 0x02cc2294, nsString &
{...}, int 0) line 695
nsEditorShell::GetContentsAsHTML(nsEditorShell * const 0x02ce8a40, unsigned
short * * 0x0012e4b0) line 1560 + 32 bytes
XPTC_InvokeByIndex(nsISupports * 0x02ce8a40, unsigned int 4, unsigned int 1,
nsXPTCVariant * 0x0012e4b0) line 135
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02b0ab70,
nsXPCWrappedNative * 0x02ce9970, const XPCNativeMemberDescriptor * 0x0214c630,
nsXPCWrappedNativeClass::CallMode CALL_GETTER, unsigned int 0, long *
0x00000000, long * 0x0012ec78) line 511 + 44 bytes
nsXPCWrappedNativeClass::GetAttributeAsJSVal(JSContext * 0x02b0ab70,
nsXPCWrappedNative * 0x02ce9970, const XPCNativeMemberDescriptor * 0x0214c630,
long * 0x0012ec78) line 524
WrappedNative_GetProperty(JSContext * 0x02b0ab70, JSObject * 0x0214aa60, long
46434480, long * 0x0012ec78) line 171 + 24 bytes
js_Interpret(JSContext * 0x02b0ab70, long * 0x0012edf8) line 2173 + 978 bytes
js_Invoke(JSContext * 0x02b0ab70, unsigned int 0, int 0) line 671 + 13 bytes
js_Interpret(JSContext * 0x02b0ab70, long * 0x0012f5e0) line 2217 + 15 bytes
js_Invoke(JSContext * 0x02b0ab70, unsigned int 1, int 0) line 671 + 13 bytes
js_InternalCall(JSContext * 0x02b0ab70, JSObject * 0x021078f8, long 34633984,
unsigned int 1, long * 0x0012f724, long * 0x0012f72c) line 749 + 15 bytes
JS_CallFunctionValue(JSContext * 0x02b0ab70, JSObject * 0x021078f8, long
34633984, unsigned int 1, long * 0x0012f724, long * 0x0012f72c) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02d10e50) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f910, nsIDOMEvent * * 0x0012f8cc, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 586 + 21 bytes
RDFElementImpl::HandleDOMEvent(RDFElementImpl * const 0x02ca96e0, nsIPresContext
& {...}, nsEvent * 0x0012f910, nsIDOMEvent * * 0x0012f8cc, unsigned int 1,
nsEventStatus & nsEventStatus_eIgnore) line 2351
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x02ca10c0, nsIPresContext & {...}, nsMouseEvent * 0x0012fb88, nsEventStatus &
nsEventStatus_eIgnore) line 671 + 31 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x02ca10c0,
nsIPresContext & {...}, nsGUIEvent * 0x0012fb88, nsIFrame * 0x02cab840,
nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x02b31cb0) line 194 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x02b318c4, nsIView * 0x02b31cb0,
nsGUIEvent * 0x0012fb88, nsEventStatus & nsEventStatus_eIgnore) line 2087 + 43
bytes
nsView::HandleEvent(nsView * const 0x02b31cb0, nsGUIEvent * 0x0012fb88, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsViewManager::DispatchEvent(nsViewManager * const 0x02b31ed0, nsGUIEvent *
0x0012fb88, nsEventStatus & nsEventStatus_eIgnore) line 1736
HandleEvent(nsGUIEvent * 0x0012fb88) line 67
nsWindow::DispatchEvent(nsWindow * const 0x02b31b84, nsGUIEvent * 0x0012fb88,
nsEventStatus & nsEventStatus_eIgnore) line 434 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb88) line 455
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3128 +
15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3281
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 6029648, long *
0x0012fdac) line 2407 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x050104d2, unsigned int 514, unsigned int 0, long
6029648) line 503 + 27 bytes
USER32! 77e71268()

I can F5 through the exception. The resulting HTML does not have color encoded
correctly:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<html>
<head></head>


<body>This is <font color>fsdfsfdsfd</font></body>
</html>

AppendToHTMLWindow:
 <HTML><FONT COLOR="#ff0000"><B>slogan622<!-- (timehere)--></B>:</FONT><!-- This
 page was created by the Gecko output system. -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<html>
<head></head>


<body>This is <font color>fsdfsfdsfd</font></body>
</html>
<BR></HTML>

Comment 1

[buster]

assigned to peter.  if it's trivial, it'd be good to get in for M8. But if it
involves any risk at all, M9 is fine.  Your call.
Changed summary from "crash" to "assert", since only debug builds will see the
assert, though everyone will see the screwy html.

Comment 2

[buster]

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

Comment 3

[Grace Bush]

Win and Mac builds 1999072208 show this fixed, but not Linux
Checking with beppe on whether to verify for Win, Mac only

Comment 4

[Peter Linss]

Please verify if it is the same stack trace on Linux. This is all cross platform
code...

Comment 5

[sujay]

Syd, I'll need your help verifying this one..let me know when you're in the
office..

Comment 6

[Syd Logan]

Looks good on Windows for us. I assume that this won't be a problem on Linux so
I'm marking verified fixed.