Closed Bug 498240 Opened 11 years ago Closed 11 years ago

Range.insertNode() causing NS_ERROR_DOM_INDEX_SIZE_ERR


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

Not set



Tracking Status
status1.9.1 --- ?


(Reporter: glen.84, Assigned: mats)



(Keywords: regression)


(4 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

See steps to reproduce. (test files to be attached)

Reproducible: Always

Steps to Reproduce:
| = caret

1. Insert the caret somewhere between the "Test content." text. e.g. "Test con|tent."
2. Press Shift+End (this is in Windows) to select until the end of the line.
3. Click "Insert"

You can also create a selection with the mouse, starting inside the text and ending after the ".".

I can also reproduce this sometimes by making a selection like: "Te|st cont|ent.", but it seems a bit intermittent.
Actual Results:  
[Exception... "Index or size is negative or greater than the allowed amount"  code: "1" nsresult: "0x80530001 (NS_ERROR_DOM_INDEX_SIZE_ERR)"  location: "file:///... Line: ..."]

Expected Results:  
Node is inserted.
Attached file Range.insertNode() bug (obsolete) —
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090612 Minefield/3.6a1pre
Component: General → DOM: Traversal-Range
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → traversal-range
Version: unspecified → Trunk
Attached file Reduced testcase
Steps to reproduce:
1) Highlight "abb".
2) Click "Insert".
Attachment #383189 - Attachment is obsolete: true
Attachment #383190 - Attachment is obsolete: true
I can't seem to reproduce this in FF, so I think this is a FF3 regression.
Inspecting the range with Venkman, I find the range's startContainer and endContainer are a text node. says:

If the start boundary point of the Range is in a Text node, the insertNode operation splits the Text node at the boundary point. If the node to be inserted is also a Text node, the resulting adjacent Text nodes are not normalized automatically; this operation is left to the application.
This works for me with Firefox 3.5 beta 4 code, though:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090428 Shiretoko/3.5b4
Bad: 3.0 Beta 1

Bisecting now...
Keywords: regression
So ... / - No bug
3.0 beta 1 / 3.0.11 - Bug
3.5 beta 4 - No bug
3.6a1pre - Bug

Anyone seeing a pattern? :-)
The differences between 3.5b4 and 3.6a1 would be far more interesting for a regression than between and 3.0.11.
The bug is present for me in 3.5b4.

Good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060223 Firefox/1.6a1
Bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060304 Firefox/1.6a1

There are problems with the Windows installers between these two dates. I'll probably have to try the Linux builds.
I encountered this error while running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5 and running
We need a more granular regression range here. Adding keyword.
OS: Windows XP → All
Hardware: x86 → All
Good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060302 Firefox/1.6a1
Bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060303 Firefox/1.6a1
bug 253609 is the likely culprit.
Backing out bug 253609 locally fixes it.
Attached patch wipSplinter Review
tEndOffset only has meaning in the subtraction if
startContainer == endContainer.  And I think we should do this also
when collapsed, as suggested in bug 253609 comment 16.
I'll read the spec some more, test other UAs and write tests tomorrow...
Assignee: nobody → matspal
Attached file Testcase #2 (obsolete) —
After reading the spec, especially the "We have chosen that in this case neither the container  nor offset  of the boundary-point is changed." bit at
I think I'll leave it as is for collapsed ranges.  I did implement extending
the range when an insertion occurs at the collapsed boundary point but it
didn't feel right for general insertions, e.g. node.insertBefore etc
and making Range.insertNode() an exception doesn't feel right either.
Attached file Testcase #2b
Attachment #383795 - Attachment is obsolete: true
Attached patch Patch rev. 1Splinter Review
Attachment #384095 - Flags: review?
Attachment #384095 - Flags: review? → review?(peterv)
(In reply to comment #19)
> I think I'll leave it as is for collapsed ranges. 
Right. InsertNode shouldn't modify collapsed range per the current DOM Range spec.
WebApps WG mailing list has a thread about this.
Can regressions be fixed retroactively, or will the fix only be released in a future version?
Flags: blocking1.9.1?
If this has been around since Firefox 3.0 Beta 1 (comment 8) and only really being noticed now, I don't think it needs to block final release. We should fix it on a stability and security branch, though.

Glen: when fixed, it will be issued to all Firefox 3.5.x users, and if back-ported, all Firefox 3.0.x users as well.
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Thanks Mike.
peterv: Can you review this?
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
Whiteboard: [needs r=peterv]
Attachment #384095 - Flags: superreview+
Attachment #384095 - Flags: review?(peterv)
Attachment #384095 - Flags: review+
Whiteboard: [needs r=peterv]
This is ready to be checked in, right? Mats?
Keywords: checkin-needed
Yes, I landed it with a mochitest:

Closed: 11 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Flags: wanted1.9.0.x?
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.