Closed Bug 2243 Opened 26 years ago Closed 25 years ago

{sink} appending text nodes to body does so twice

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tupshin, Assigned: vidur)

References

(
URL
)

Details

(Whiteboard: [TESTCASE])

Attachments

(2 files)

Test for secondary hilighting bug.
(deleted), text/html
Details
New and improved test case
(deleted), text/html
Details
<body> <script> mybody=document.getElementsByTagName('body'); my_text_node=document.createTextNode('this is a test'); mybody[0].appendChild(my_text_node); mybody[0].appendChild(my_text_node); </script> </body> The above code attempts to append my_text_node to the body element of the document. Every time the appendChild method is called, the contents of my_text_node shows up twice. In the above example it shows up four times.
Status: NEW → ASSIGNED
Setting all current Open Critical and Major to M3
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Additional info - the extra text seems to be inserted at the start of the document. see http://steveapp.home.mindspring.com/mozillabug/DoubleText.html.
QA Contact: 4015 → 4078
QA contact re-assigned according to the product areas we're currently working on.
Target Milestone: M3 → M4
Target Milestone: M4 → M5
Troy, the problem occurs because the DOM insertion methods result in immediate frame construction. This done before the document has finished loading. When the document does finish loading, the HTMLContentSink does a ContentAppended notification. Since it didn't know that content had been added by the DOM, it causes frame construction to reoccur for the new content. Any thoughts?
Good catch! I have a fix in my local tree. Waiting for M4 to branch so I can check it in for M5.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fix checked in on 4/13. Content added via the DOM during document loading could result in multiple frames being created for each element. This was because the DOM would cause immediate creation of frames and the HTML content sink does incremental layout. We now update the sink's notion of what's laid out every time a script is evaluated.
Status: RESOLVED → VERIFIED
OS: Windows NT → All
Hardware: PC → All
(this was an XP bug) verified on the M4 builds on RedHat 5.2, MacOS 8.51, and WinNT 4 sp4 (M4 builds have id's 1999-04-1[34])
Not sure how this was verified on M4 when I checked it in on 4/13 into the tip.
Status: VERIFIED → REOPENED
ok, somebody put crack in my cereal.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
sorry about that. i could have sworn it was fixed. (bad qa engineer!)
Status: RESOLVED → VERIFIED
ok, i swear this time. verified on: RedHat 5.2 i386 build 1999-04-15-08 WinNT 4.0 sp 4 build 1999-04-15-08 MacOS 8.51 build 1999-04-15-08
Status: VERIFIED → REOPENED
the behavior reappeared recently. builds tested: 1999-05-17-08 RedHat 5.2 i386 apprunner 1999-05-17-09 MacOS 8.51 apprunner 1999-05-17-08 WinNT 4 sp3 apprunner new testcase: same as the old testcase, but add a 'document.write("<br>");' just before the script closes: <BODY> <SCRIPT type="text/javascript"> var oBody = document.getElementsByTagName('BODY').item(0); var txt1 = document.createTextNode( "this is a test." ); oBody.appendChild( txt1 ); document.write( "<BR>" ); </SCRIPT> </BODY>
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: M5 → M7
Hmmm....related to bug 6092. The logic I worked out for the original bug doesn't work for a mixture of document.written and DOM-added content. Back to the drawing board. *sigh*
Attached file Test for secondary hilighting bug. (deleted) —
Oops, added the attachment ot the wrong bug.
Assignee: vidur → peterl
Status: ASSIGNED → NEW
Target Milestone: M7
Peter, this is the bug that I mentioned the other day w.r.t. the way the HTMLContentSink adds content to the document. I'm reassigning it to you so that you can keep it in mind when you rework that code. Note that there is code in the HTMLContentSink (PreEvaluateScript() and PostEvaluateScript()) that attempt to deal with DOM additions while the document is loading. Unfortunately, they don't deal with all cases. Let's talk if you have questions about DOM expectations.
Blocks: 6092
Attached file New and improved test case (deleted) —
Status: NEW → ASSIGNED
Target Milestone: M8
Target Milestone: M8 → M9
*** Bug 6092 has been marked as a duplicate of this bug. ***
If you try using the mouse to select the text only 1 of them will be highlighted
Whiteboard: [TESTCASE]
Summary: appending text nodes to body does so twice → {sink} appending text nodes to body does so twice
Target Milestone: M9 → M10
Moving all content sink issues to M14.
Make that M14.
Thanks for taking this Vidur. Many of these are likely dups. I haven't marked them as such to make sure I had the testcases handy...
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Fixed with sink changes on 10/26/1999.
QA Contact: phillip → ckritzer
The original bug is not very clear to me. Is the first testcase (supplied by originator) *supposed* to append the text twice (once for each appendChild)? Or is it only supposed to append the text once, in spite of how many times it is appended?
The original test case appended the same text node twice. As a result, it should only show up once in the content model and on screen. The revised test case from Peter mixes an append and a document.write. Both should show up in the content model.
Coolness. Marking VERIFIED FIXED on: - Linux6 2000-02-21-08 Commercial build - MacOS9 2000-02-21-08 Commercial build - Win98 2000-02-21-08 Commercial build
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: