Closed
Bug 498240
Opened 15 years ago
Closed 15 years ago
Range.insertNode() causing NS_ERROR_DOM_INDEX_SIZE_ERR
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
status1.9.1 | --- | ? |
People
(Reporter: glen.84, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: regression)
Attachments
(4 files, 3 obsolete files)
543 bytes,
text/html
|
Details | |
1.75 KB,
patch
|
Details | Diff | Splinter Review | |
7.19 KB,
text/html
|
Details | |
10.47 KB,
patch
|
peterv
:
review+
peterv
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 3•15 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•15 years ago
|
||
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 2.0.0.18, so I think this is a FF3 regression.
Comment 6•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
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
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? :-)
Comment 10•15 years ago
|
||
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•15 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.
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
We need a more granular regression range here. Adding keyword.
Comment 14•15 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•15 years ago
|
||
bug 253609 is the likely culprit.
Assignee | ||
Comment 16•15 years ago
|
||
Backing out bug 253609 locally fixes it.
Blocks: 253609
Keywords: regressionwindow-wanted
Assignee | ||
Comment 17•15 years ago
|
||
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•15 years ago
|
||
Assignee | ||
Comment 19•15 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•15 years ago
|
||
Attachment #383795 -
Attachment is obsolete: true
Assignee | ||
Comment 21•15 years ago
|
||
Attachment #384095 -
Flags: review?
Assignee | ||
Updated•15 years ago
|
Attachment #384095 -
Flags: review? → review?(peterv)
Comment 22•15 years ago
|
||
(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•15 years ago
|
||
Can regressions be fixed retroactively, or will the fix only be released in a future version?
Flags: blocking1.9.1?
Comment 24•15 years ago
|
||
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•15 years ago
|
||
Thanks Mike.
Comment 26•15 years ago
|
||
peterv: Can you review this?
Updated•15 years ago
|
Attachment #384095 -
Flags: superreview+
Attachment #384095 -
Flags: review?(peterv)
Attachment #384095 -
Flags: review+
Updated•15 years ago
|
Whiteboard: [needs r=peterv]
Assignee | ||
Comment 28•15 years ago
|
||
Yes, I landed it with a mochitest: http://hg.mozilla.org/mozilla-central/rev/0dfc4dfaa370 -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Updated•13 years ago
|
Flags: wanted1.9.0.x?
Updated•11 years ago
|
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•