[FIX]document.write on already open document clears it in some cases

RESOLVED FIXED in mozilla1.9alpha1



DOM: Core & HTML
11 years ago
11 years ago


(Reporter: Christian Myksvoll, Assigned: bz)


(4 keywords)

fixed1.8.0.4, fixed1.8.1, regression, testcase
Bug Flags:
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)




(4 attachments, 1 obsolete attachment)



11 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: All FireFox versions from version 1.5

The bug has been there since FireFox version 1.5.

Check the provided forum link: 

In addition check this URL for a test:

Click TWO times on Button 1, then ONCE on Button 2. IE6 (and all other major browsers) then displays: content1, content2, content3, content4. 
FireFox 1.5/2.0a1 displays only: content3, content4. 

Reproducible: Always

Steps to Reproduce:
Check Details
Actual Results:  
Check Details

Expected Results:  
Check Details
Created attachment 216126 [details]
testcase from reporter's URL


11 years ago
Keywords: testcase


11 years ago
Attachment #216126 - Attachment is obsolete: true


11 years ago
Keywords: testcase
1.8b2_2005060906 works
1.8b2_2005061006 fails
No idea what happened with Steve's testcase :)
Regression range from comment 2

The testcase was dependent on externally held files (my bad) so I obsolete'd it.
Keywords: regression
With that regression range, I guess this could be a regression from bug 295983.
Assignee: nobody → general
Component: General → DOM: Level 0
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Please do attach a usable testcase to the bug instead of hosting it somewhere else?

This is a pretty major regression....  I'll try to figure it out when I get back, I guess, if no one does by then.
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
Keywords: helpwanted

Comment 6

11 years ago
Created attachment 216307 [details]
Test case.

Open index.html in the browser.
bz: when you get a chance to look at this let us know if you still think it's safe and sane for the 1.8.0 branch
Assignee: general → bzbarsky


11 years ago
Attachment #216307 - Attachment mime type: text/html → application/zip

Comment 8

11 years ago
BTW: These assertions happen when clicking Button1 for the second time:
###!!! ASSERTION: Found more undisplayed content data after removal: 'context ==
 nsnull', file h:/mozilla/tree-main/mozilla/layout/base/nsFrameManager.cpp, line
###!!! ASSERTION: EndLoad called early: 'mWriteState == eNotWriting || mWriteSta
te == ePendingClose || mWriteState == eDocumentClosed', file h:/mozilla/tree-mai
n/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1031

And these when clicking on Button2 then:
###!!! ASSERTION: Found more undisplayed content data after removal: 'context ==
 nsnull', file h:/mozilla/tree-main/mozilla/layout/base/nsFrameManager.cpp, line
###!!! ASSERTION: nsHTMLDocument::Reset() - Wyciwyg Channel  still exists!: '!mW
yciwygChannel', file h:/mozilla/tree-main/mozilla/content/html/document/src/nsHT
MLDocument.cpp, line 426

But not sure how far those are related to a bad state in general, since the throbber does not stop spinning after clicking Button1 (this also happens in builds without that regression).
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Testcase URI:

(In reply to comment #6)
> Test case.
> Open index.html in the browser.

With seamonkey(2006040110-trunk/Win-2K), problem couldn't be created when fisrt click of button1(document.close&open, document.write content1/2) after Load folowed by several clicks fo butron2(write content3/4), but problem was re-created when second or later series of click of button1 and button2's(no assertion was observed).
Putting alert('Hello') between document.close() and document.open() was a effective workaround of this bug's phenomenon.
Seriarization of document.close() and document.open() is required?

(In reply to comment #9)
> jar:https://...
Oh, it's a nice feature!
I can easily attach zip file as attachment of test cases. 
Created attachment 217117 [details] [diff] [review]

The idea is really simple.  Since the close() and following write() have already terminated the mParser we set the termination function for, the termination function shouldn't mess with it.  That means the termination function should know what parser it's supposed to be terminating.

Note that I could _maybe_ have gotten to the document from the parser, but passing both in seems to be safer.

I do think this is safe for the branches.

With this fix we still get the undisplayed content assertions -- that's bug 332644.
Attachment #217117 - Flags: superreview?(jst)
Attachment #217117 - Flags: review?(mrbkap)
Attachment #217117 - Flags: approval-branch-1.8.1?(jst)
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: document.write clears the document content → [FIX]document.write on already open document clears it in some cases
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 217117 [details] [diff] [review]

Attachment #217117 - Flags: review?(mrbkap) → review+
Comment on attachment 217117 [details] [diff] [review]

Attachment #217117 - Flags: superreview?(jst) → superreview+
Fixed on trunk.
Last Resolved: 11 years ago
Keywords: helpwanted
Resolution: --- → FIXED
Attachment #217117 - Flags: approval1.8.0.3?


11 years ago
Attachment #217117 - Flags: approval-branch-1.8.1?(jst) → approval-branch-1.8.1+
Comment on attachment 217117 [details] [diff] [review]

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #217117 - Flags: approval1.8.0.3? → approval1.8.0.3+
Created attachment 219708 [details] [diff] [review]
1.8 branch patch
Created attachment 219710 [details] [diff] [review]
1.8.0 branch patch
Fixed on both branches.
Keywords: fixed1.8.0.3, fixed1.8.1
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.