1259949 - <textarea> displays caret on wrong line after selecting \n if it's the last symbol

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160324030447
STR:
1. Open attached "testcase 1"  (text in <textarea> is "asdf\n")
2. Select any text including the last "\n" in testcase, for example:
 Click between "s" and "d", press Shift+Down to select "df\n"
3. Press Right key to move cursor to the end of text selection
4. Type "x"

Result:       
 After Step 3 cursor is displayed at the end of the 1st line
 After Step 4 the typed letter ("x") appears in the beginning of the 2nd line

Expectations:
 After Step 3 cursor should be displayed at the start of the 2nd line

Comment 2

[Mats Palmgren (inactive)]

In this case we have a DOM like so:
<anonymous-div>
  "asdf\n"
  <br>

and we Collapse() at <anonymous-div> : 1

So that makes do_QueryFrame(aParentNode.AsContent()->GetPrimaryFrame())
null since the frame we get there isn't a text frame - it's a scroll frame
for the <anonymous-div>.  To my surprise though, nsCaret::GetFrameAndOffset
seems to deal with this and does return the text frame (if I remove the
initial null-check on 'f').  We would need to tweak the aOffset check on
line 4948 though since it isn't a text offset in this case.
http://hg.mozilla.org/mozilla-central/annotate/63be002b4a80/layout/generic/nsSelection.cpp#l4940

Comment 3

[Mats Palmgren (inactive)]

Attachment: fix

(see explanation of the problem in comment 2)

Comment 4

[Mats Palmgren (inactive)]

Attachment: tests

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2612040c9605

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2e97b6bf18de
https://hg.mozilla.org/integration/mozilla-inbound/rev/74f7a5eba75e

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2e97b6bf18de
https://hg.mozilla.org/mozilla-central/rev/74f7a5eba75e

Comment 7

[arni2033]

Fixed on: Win7_64, Nightly 48, 32bit, ID 20160401030216

Bug 1237286 is still reproducible