From bug 302050 comment 57: I'm noticing lots of inline spell checker assertions when closing a mail composition window after this change went in. The message has already been sent, and while we are closing the compose window it looks like we now end up trying to spell check the document again. Probably a collision between these spell check changes and the recycled compose window. brett can you reproduce these assertions too? nsContentIterator::First() line 965 + 41 bytes nsFilteredContentIterator::First() line 158 nsTextServicesDocument::FirstTextNode(nsIContentIterator * 0x04bb2ae0, nsTextServicesDocument::TSDIteratorStatus * 0x04bd947c) line 4118 nsTextServicesDocument::FirstBlock(nsTextServicesDocument * const 0x04bd9468) line 601 + 24 bytes nsTextServicesDocument::SetExtent(nsTextServicesDocument * const 0x04bd9468, nsIDOMRange * 0x046c4b88) line 354 + 12 bytes mozInlineSpellChecker::SpellCheckRange(nsIDOMRange * 0x049d1770, nsISelection * 0x04b68520) line 964 + 47 bytes mozInlineSpellChecker::SpellCheckBetweenNodes(nsIDOMNode * 0x04b694b4, int 0, nsIDOMNode * 0x04b694b4, int 0, nsISelection * 0x04b68520) line 707 + 26 bytes mozInlineSpellChecker::SpellCheckRange(mozInlineSpellChecker * const 0x04bdf7c0, nsIDOMRange * 0x00000000) line 405 + 39 bytes mozInlineSpellChecker::SpellCheckAfterEditorChange(mozInlineSpellChecker * const 0x04bdf7c0, int 3013, nsISelection * 0x04b68488, nsIDOMNode * 0x04b694b4, int 0, nsIDOMNode * 0x04b694b4, int 0, nsIDOMNode * 0x04b694b4, int 0) line 344 nsEditor::HandleInlineSpellCheck(int 3013, nsISelection * 0x04b68488, nsIDOMNode * 0x04b694b4, int 0, nsIDOMNode * 0x04b694b4, int 0, nsIDOMNode * 0x04b694b4, int 0) line 5327 + 73 bytes nsHTMLEditRules::AfterEditInner(int 3013, short 1) line 547 + 78 bytes nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x04b969bc, int 3013, short 1) line 391 + 20 bytes nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x04b51080) line 4133 + 62 bytes nsAutoRules::~nsAutoRules() line 125 nsHTMLEditor::LoadHTML(nsHTMLEditor * const 0x04b51080, const nsAString_internal & {...}) line 244 + 85 bytes nsHTMLEditor::RebuildDocumentFromSource(nsHTMLEditor * const 0x04b5115c, const nsAString_internal & {...}) line 1797 + 70 bytes XPTC_InvokeByIndex(nsISupports * 0x04b5115c, unsigned int 20, unsigned int 1, nsXPTCVariant * 0x0012e508) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2139 + 43 bytes XPC_WN_CallMethod(JSContext * 0x01980ea0, JSObject * 0x0493b390, unsigned int 1, long * 0x049bedb0, long * 0x0012e7d4) line 1444 + 14 bytes js_Invoke(JSContext * 0x01980ea0, unsigned int 1, unsigned int 0) line 1211 + 23 bytes js_Interpret(JSContext * 0x01980ea0, unsigned char * 0x047b6ea6, long * 0x0012f294) line 3754 + 15 bytes js_Invoke(JSContext * 0x01980ea0, unsigned int 0, unsigned int 2) line 1231 + 19 bytes nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x049a8c10, nsXPCWrappedJS * 0x049a8cc0, unsigned short 3, const nsXPTMethodInfo * 0x03534708, nsXPTCMiniVariant * 0x0012f5dc) line 1376 + 22 bytes nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x049a8cc0, unsigned short 3, const nsXPTMethodInfo * 0x03534708, nsXPTCMiniVariant * 0x0012f5dc) line 466 PrepareAndDispatch(nsXPTCStubBase * 0x049a8cc0, unsigned int 3, unsigned int * 0x0012f68c, unsigned int * 0x0012f67c) line 117 + 31 bytes SharedStub() line 147 nsMsgCompose::CloseWindow(nsMsgCompose * const 0x04a68218, int 1) line 1276

This fixes the assertions I found regarding spellchecking in Thunderbird: close compose window (usually only the first time), and clicking in a new empty compose window the first time.

Comment on attachment 215795 [details] [diff] [review] Patch This looks good to me. Thanks a lot Brett.

On trunk, leaving open so I don't forget to check in to branch.

This was fixed on branch by bug 329668.