ASSERTION: whoa nelly. this shouldn't happen: 'startIdx != endIdx', file nsRange.cpp, line 705

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
12 years ago
10 years ago

People

(Reporter: mats, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, regression})

Trunk
x86
Linux
assertion, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

12 years ago
455 bytes, text/html
Details
(Reporter)

Comment 1

12 years ago
Created attachment 234624 [details]
stack

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
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

Comment 4

12 years ago
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.

Comment 5

12 years ago
I haven't been able to reproduce this since bug 347165 landed.
Maybe we should just declare that range consumers Should Not Do That and document accordingly?
Call nsRange::ComparePoints on nodes that are not in the same connected tree.

Comment 10

10 years ago
bz, I think the patch in bug 409380 kinda did what you wanted.
Group: core-security
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
OK. Let's get the crashtest in?
Flags: in-litmus?

Comment 12

10 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.