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

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
DOM: Core & HTML
P1
normal
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Christian Myksvoll, Assigned: bz)

Tracking

(4 keywords)

Trunk
mozilla1.9alpha1
fixed1.8.0.4, fixed1.8.1, regression, testcase
Points:
---
Bug Flags:
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

12 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: 
http://forums.mozillazine.org/viewtopic.php?p=2166546#2166546

In addition check this URL for a test:
http://www.edialog24.com/tmp/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

Updated

12 years ago
Keywords: testcase

Updated

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

Updated

12 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
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-09+05&maxdate=2005-06-10+07&cvsroot=%2Fcvsroot

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
Status: UNCONFIRMED → NEW
Component: General → DOM: Level 0
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
(Assignee)

Comment 5

12 years ago
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
(Reporter)

Comment 6

12 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

Updated

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

Comment 8

12 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
 628
###!!! 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
 628
###!!! 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+
(Assignee)

Comment 9

12 years ago
Testcase URI:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=216307!/index.html
(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. 
(Assignee)

Comment 11

12 years ago
Created attachment 217117 [details] [diff] [review]
Fix

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)
(Assignee)

Updated

12 years ago
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]
Fix

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

sr=jst
Attachment #217117 - Flags: superreview?(jst) → superreview+
(Assignee)

Comment 14

12 years ago
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: helpwanted
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #217117 - Flags: approval1.8.0.3?

Updated

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

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #217117 - Flags: approval1.8.0.3? → approval1.8.0.3+
(Assignee)

Comment 16

11 years ago
Created attachment 219708 [details] [diff] [review]
1.8 branch patch
(Assignee)

Comment 17

11 years ago
Created attachment 219710 [details] [diff] [review]
1.8.0 branch patch
(Assignee)

Comment 18

11 years ago
Fixed on both branches.
Keywords: fixed1.8.0.3, fixed1.8.1
(Assignee)

Updated

11 years ago
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.