Closed Bug 420700 Opened 17 years ago Closed 17 years ago

Calling createContextualFragment affects subsequent setting of innerHTML

Categories

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

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sevenfurnace, Assigned: bent.mozilla)

Details

(Keywords: regression)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030303 Minefield/3.0b4pre When you call range.createContextualFragment, and then set innerHTML on an element, the element contains the contents of DocumentFragment created by createContextualFragment. Reproducible: Always Steps to Reproduce: 1.Create DocumentFragment by calling range.createContextualFragment 2.Set some string to an element's innerHTML Actual Results: The element additionally includes the contents of DocumentFragment created by createContextualFragment. Expected Results: The element contains only what was assigned.
Attached file testcase
Version: unspecified → Trunk
My guess is that Bug 386769 may have caused this.
Seems pretty likely.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Assignee: nobody → bent.mozilla
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached patch Patch, v1Splinter Review
The basic problem is that the content sink expects to have a short lifetime and therefore not really hang on to the document fragment it produces. That doesn't work well with caching if we then hand the fragment off to some random caller.
Attachment #307619 - Flags: review?(jst)
Comment on attachment 307619 [details] [diff] [review] Patch, v1 r+sr=jst
Attachment #307619 - Flags: superreview+
Attachment #307619 - Flags: review?(jst)
Attachment #307619 - Flags: review+
Can you add a mochitest for this as well?
Flags: in-testsuite?
Comment on attachment 307619 [details] [diff] [review] Patch, v1 Oops, this is blocking.
Attachment #307619 - Flags: approval1.9?
This is what I just landed, with a mochitest.
Fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041323 Minefield/3.0pre ID:2008041323 and the testcase from comment #1
Status: RESOLVED → VERIFIED
Component: DOM: Core → 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: