Closed Bug 765799 Opened 12 years ago Closed 12 years ago

newOffset used uninitialized in nsRange::InsertNode

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla16
Tracking Status
firefox13 --- unaffected
firefox14 --- fixed
firefox15 --- fixed
firefox16 --- fixed

People

(Reporter: Ms2ger, Assigned: ayg)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [qa-])

Attachments

(1 file)

Aryeh, could you fix?
Component: Editor → DOM: Core & HTML
QA Contact: editor → general
Assignee: nobody → ayg
Status: NEW → ASSIGNED
So the problem here is that bug 433662 comment 29 asked that we not compute newOffset unless necessary, because IndexOf is not so fast.  But I didn't account for the weird corner case in which inserting the node could collapse the range.  This should happen only when the range is from (parent, n) to (parent, n + 1), and when the node you're inserting is the nth child of parent.  Then it's removed (collapsing the range), and then reinserted (but the range is still collapsed).

I'll try to rewrite this to not use IndexOf at all.
Attached patch Patch v1Splinter Review
You asked in bug 433662 comment 29 that I compute newOffset only if needed, but it turns out it's not easy to figure out in advance whether it's needed.  The insertBefore could cause the range to collapse if it wasn't already collapsed, because the node we're inserting might be the only thing in the range.  There are a bunch of ways this could happen, and checking for them in advance would be error-prone, take a lot of code, and probably be more expensive in most cases than just doing IndexOf().  Also, we can't do RemoveChild before checking Collapsed(), because InsertBefore might throw before removing the child.  So I don't see any way to do this correctly without computing IndexOf() in advance every time.

Try: https://tbpl.mozilla.org/?tree=Try&rev=cd4b680961bf
Attachment #634310 - Flags: review?(bugs)
(in-testsuite+ because of bug 765177)
Flags: in-testsuite+
Try run without other patches that cause unrelated failures: https://tbpl.mozilla.org/?tree=Try&rev=40e761d3f9c5
Attachment #634310 - Flags: review?(bugs) → review+
Comment on attachment 634310 [details] [diff] [review]
Patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 433662 (Firefox 14)

User impact if declined: Small, but it is a regression.  An uninitialized variable is used when an author script calls the Range.insertNode method, and passes as its argument a node that's already at or contains the start of the range.  Then the range can become collapsed, which causes SetEnd() to be called with the uninitialized variable.  This will most likely cause an exception to be incorrectly thrown due to out-of-range index, and the range to remain collapsed.

Testing completed (on m-c, etc.): None yet, because I'm requesting approval concurrently with committing to m-i.

Risk to taking this patch (and alternatives if risky): The patch is very low-risk.  All it does is remove the conditional if (Collapsed()) { ... } and run the contents of the block unconditionally, so that the variable in question is always initialized.  In the common case where the bug doesn't occur, the variable won't be used, so there's no behavior change.  In the rare case where the bug does occur, it will be prevented.  There's extensive W3C testing of Range.insertNode <http://w3c-test.org/webapps/DOMCore/tests/approved/Range-insertNode.html>, and this patch causes Firefox to pass all tests.  The block of code that's being made unconditional was intended to be unconditional to start with, but was made (incorrectly) conditional to avoid unnecessary computation.

String or UUID changes made by this patch: None
Attachment #634310 - Flags: approval-mozilla-beta?
Attachment #634310 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/e82037b16e21
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 634310 [details] [diff] [review]
Patch v1

[Triage Comment]
Little to no risk (as compared to current behavior) - let's land on all branches.
Attachment #634310 - Flags: approval-mozilla-beta?
Attachment #634310 - Flags: approval-mozilla-beta+
Attachment #634310 - Flags: approval-mozilla-aurora?
Attachment #634310 - Flags: approval-mozilla-aurora+
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: