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.
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.
Maybe we should just declare that range consumers Should Not Do That and document accordingly?
Should not do what exactly?
Call nsRange::ComparePoints on nodes that are not in the same connected tree.
Ah, i'm fine with that.
bz, I think the patch in bug 409380 kinda did what you wanted.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
OK. Let's get the crashtest in?
I checked the testcase in as a crashtest, using a reftest-wait and a shorter timeout.
You need to log in before you can comment on or make changes to this bug.