Closed Bug 454746 Opened 16 years ago Closed 5 years ago

"ASSERTION: Start parent and end parent give different root!" with XBL, ranges

Categories

(Core :: XBL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, testcase)

Attachments

(1 file)

1.34 KB, application/xhtml+xml
Details
Attached file testcase
###!!! ASSERTION: Start parent and end parent give different root!: 'newRoot == IsValidBoundary(mEndParent)', file /Users/jruderman/central/content/base/src/nsRange.cpp, line 352

###!!! ASSERTION: Wrong root: '!aRoot || (nsContentUtils::ContentIsDescendantOf(aStartN, aRoot) && nsContentUtils::ContentIsDescendantOf(aEndN, aRoot) && aRoot == IsValidBoundary(aStartN) && aRoot == IsValidBoundary(aEndN))', file /Users/jruderman/central/content/base/src/nsRange.cpp, line 443
This is fun.  The basic issue is that we issue no notification (like say ContentRemoved) when removing the XBL anonymous content on binding teardown.  So the range has no idea that the <h:span> node there got removed, and doesn't update its endpoints.  Then when we mess around with the DOM it doesn't know (because it's observing the HTMLElement, which doesn't get those notifications from the disconnected subtree), and gets all confused.
Flags: blocking1.9.1?
Ugh, tricky. I don't really know a good solution. A solution (though complicated) would be to force ranges never to go into anonymous trees. So if you for example select into a binding we'd create two ranges, one inside the binding and one outside...

For extra credit, apply to nested bindings :(
Or we could notify in some way when the anonymous content of a binding is removed from the tree, right?  Note that in this case the range is entirely inside the binding's anonymous contet to start with, so your proposed solution wouldn't help anyway.
Good point. That seems like a simpler solution
OS: Mac OS X → All
Not a blocker unless we think this can result in exploitable crashes.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
I think this can also lead to:

###!!! ASSERTION: Bad root: '!aRoot || (aStartN->IsNodeOfType(nsINode::eCONTENT) && aEndN->IsNodeOfType(nsINode::eCONTENT) && aRoot == static_cast<nsIContent*>(aStartN)->GetBindingParent() && aRoot == static_cast<nsIContent*>(aEndN)->GetBindingParent()) || (!aRoot->GetNodeParent() && (aRoot->IsNodeOfType(nsINode::eDOCUMENT) || aRoot->IsNodeOfType(nsINode::eATTRIBUTE) || aRoot->IsNodeOfType(nsINode::eDOCUMENT_FRAGMENT) || aRoot->IsNodeOfType(nsINode::eCONTENT)))', file /Users/jruderman/central/content/base/src/nsRange.cpp, line 454
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: