Closed Bug 498240 Opened 11 years ago Closed 11 years ago
.insert Node() causing NS _ERROR _DOM _INDEX _SIZE _ERR
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:188.8.131.52) 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:184.108.40.206) 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.
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
Steps to reproduce: 1) Highlight "abb". 2) Click "Insert".
I can't seem to reproduce this in FF 220.127.116.11, 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
Good: 18.104.22.168 Bad: 3.0 Beta 1 Bisecting now...
So ... 22.214.171.124 / 126.96.36.199 - 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 188.8.131.52 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 https://litmus.mozilla.org/show_test.cgi?id=6172.
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.
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
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.
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?
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.
This is ready to be checked in, right? Mats?
Yes, I landed it with a mochitest: http://hg.mozilla.org/mozilla-central/rev/0dfc4dfaa370 -> FIXED
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.