BUILD: Current debug build STEPS TO REPRODUCE: 1) Open a blank window 2) javascript:void(document.open()) 3) Hit the stop button 4) javascript:void(document.open()) EXPECTED RESULTS: no asserts ACTUAL RESULTS: After step 2: ###!!! ASSERTION: EndLoad called early: 'mWriteState == eNotWriting || mWriteState == ePendingClose || mWriteState == eDocumentClosed', file ../../../../../mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1031 ###!!! ASSERTION: More UnblockOnload() calls than BlockOnload() calls; dropping call: 'Not Reached', file ../../../../mozilla/content/base/src/nsDocument.cpp, line 5176 And after step 4: ###!!! ASSERTION: nsHTMLDocument::Reset() - Wyciwyg Channel still exists!: '!mWyciwygChannel', file ../../../../../mozilla/content/html/document/src/nsHTMLDocument.cpp, line 426 For this last one, we should probably implement StopDocumentLoad in nsHTMLDocument and call RemoveWyciwygChannel() in it or something.... Not sure about the other two.

Bug 326621 has some of the assertions.

I plan on working on this soon.

The comment basically says it. If we've had a document.open call, simply terminating our parser will cause all sorts of unhappiness. This patch simply calls close() on the parser when the user hits the stop button. The one thing that I'm worried about is that if there are pending script loads, this might asynchonously wait until the scripts finish loading (or their loads are stopped) before calling EndLoad on the document. I don't think this is likely to be a problem, though...

Comment on attachment 217461 [details] [diff] [review] Proposed fix Hmm.. I guess this works. Check that this works ok in the termination func case (eg. when location is set from JS on a document that's being written to)!

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