Range.insertNode() causing NS_ERROR_DOM_INDEX_SIZE_ERR

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Glen A., Assigned: mats)

Tracking

({regression})

Trunk
mozilla1.9.3a1
regression
Points:
---
Bug Flags:
blocking1.9.1 -
in-testsuite +

Firefox Tracking Flags

(status1.9.1 ?)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11) 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:1.9.0.11) 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.
(Reporter)

Comment 1

9 years ago
Created attachment 383189 [details]
Range.insertNode() bug
(Reporter)

Comment 2

9 years ago
Created attachment 383190 [details]
iframe.htm, required by previous attachment (ff-bug.htm)

Comment 3

9 years ago
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090612 Minefield/3.6a1pre
Status: UNCONFIRMED → NEW
Component: General → DOM: Traversal-Range
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → traversal-range
Version: unspecified → Trunk

Comment 4

9 years ago
Created attachment 383216 [details]
Reduced testcase

Steps to reproduce:
1) Highlight "abb".
2) Click "Insert".
Attachment #383189 - Attachment is obsolete: true
Attachment #383190 - Attachment is obsolete: true
(Reporter)

Comment 5

9 years ago
I can't seem to reproduce this in FF 2.0.0.18, 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.

http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html#Level-2-Range-Inserting 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

Comment 8

9 years ago
Good: 2.0.0.20
Bad: 3.0 Beta 1

Bisecting now...
Keywords: regression
(Reporter)

Comment 9

9 years ago
So ...

2.0.0.18 / 2.0.0.20 - 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 2.0.0.20 and 3.0.11.

Comment 11

9 years ago
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 https://litmus.mozilla.org/show_test.cgi?id=6172.
We need a more granular regression range here. Adding keyword.
Keywords: regressionwindow-wanted
OS: Windows XP → All
Hardware: x86 → All

Comment 14

9 years ago
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

Comment 15

9 years ago
bug 253609 is the likely culprit.
(Assignee)

Comment 16

9 years ago
Backing out bug 253609 locally fixes it.
Blocks: 253609
Keywords: regressionwindow-wanted
(Assignee)

Comment 17

9 years ago
Created attachment 383612 [details] [diff] [review]
wip

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
(Assignee)

Comment 18

9 years ago
Created attachment 383795 [details]
Testcase #2
(Assignee)

Comment 19

9 years ago
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
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html#Level-2-Range-Insertions-h3
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.
(Assignee)

Comment 20

9 years ago
Created attachment 384094 [details]
Testcase #2b
Attachment #383795 - Attachment is obsolete: true
(Assignee)

Comment 21

9 years ago
Created attachment 384095 [details] [diff] [review]
Patch rev. 1
Attachment #384095 - Flags: review?
(Assignee)

Updated

9 years ago
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.
(Reporter)

Comment 23

9 years ago
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-
(Reporter)

Comment 25

9 years ago
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
(Assignee)

Comment 28

9 years ago
Yes, I landed it with a mochitest:
http://hg.mozilla.org/mozilla-central/rev/0dfc4dfaa370

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 9 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
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.