Closed
Bug 349355
Opened 18 years ago
Closed 16 years ago
ASSERTION: whoa nelly. this shouldn't happen: 'startIdx != endIdx', file nsRange.cpp, line 705
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: MatsPalmgren_bugz, Unassigned)
References
()
Details
(Keywords: assertion, regression)
Attachments
(1 file)
18 years ago
455 bytes,
text/html
|
Details |
The problem seems to be that some ancestors are not in the document anymore.
Perhaps we should test |node->GetCurrentDoc() != nsnull| when setting up
the ancestor arrays and make an early return if it is null?
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/base/src/nsRange.cpp&rev=1.206&root=/cvsroot&mark=641-651,705#625
![]() |
||
Comment 3•18 years ago
|
||
So the real issue here is that we removed a whole subtree from inside the form. This subtree looks something like:
<span>
<input type="submit">
<label></label>
</span>
and the input being removed triggers a search for the new default submit element, which tries to sort the form.elements (and non-elements, but whatever). But the <label> is still in that list (because it's not been unbound yet), even though it's no longer in the form.
Whatever we do in the range code, nuking the use of the form control enumerator here (bug 347165) should help.
Blocks: 302186
Keywords: regression
I have a patch locally for bug 347165 which also fixes this bug. It doesn't try to sort the label because it can't possibly be a submit element.
I haven't been able to reproduce this since bug 347165 landed.
![]() |
||
Comment 6•18 years ago
|
||
Maybe we should just declare that range consumers Should Not Do That and document accordingly?
Should not do what exactly?
![]() |
||
Comment 8•18 years ago
|
||
Call nsRange::ComparePoints on nodes that are not in the same connected tree.
Ah, i'm fine with that.
Comment 10•16 years ago
|
||
bz, I think the patch in bug 409380 kinda did what you wanted.
Group: core-security
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Comment 12•16 years ago
|
||
I checked the testcase in as a crashtest, using a reftest-wait and a shorter timeout.
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus-
You need to log in
before you can comment on or make changes to this bug.
Comment 1
•