Open Bug 1306301 Opened 4 years ago Updated 4 years ago

Calling setSelectionRange() on a Textarea element doesn't reset the saved cursor position


(Core :: DOM: Selection, defect)

49 Branch
Windows 10
Not set





(Reporter: pavel.rybin, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

When you move the cursor around with the Up and Down arrow keys in a textarea, the textarea appears to keep track internally of the right-most cursor position has occupied. E.g., given a textarea with the following text:

Badger Badger

If you put the cursor at the end of the 3rd line, and press Up arrow twice, the cursor will end up positioned after the 2nd 'g' on the first line.

It seems that the setSelectionRange() JavaScript function doesn't re-set the saved value of the cursor position. If I have a keydown event handler that calls setSelectionRange(), and then use Shift+Down arrow to make a text selection, the selection gets extended to the last place the cursor was before setSelectionRange() was called.

To give a concrete example, consider the following:

1) Using the mouse, place the cursor at the end of line 3.
2) Press Up arrow once.
3) Press the Home key.
4) Press Shift+Down arrow.

The top 2 lines will be selected, whereas I would expect the selection to cover the first line only.

Reproduced on Firefox 49.0.1, on Windows 10 with the latest updates.

Actual results:

Calling setSelectionRange() on a textarea appears to cause subsequent keyboard selections done using Shift+Up/Down arrow to be incorrect. In the example given above, the selection should extend to the start of the 2nd line, but instead both of the 1st and 2nd lines are selected.

Expected results:

Calling setSelectionRange() should reset any cursor position state saved internally. In the example given above, only the 1st line should be selected by the end.
Component: Untriaged → Selection
Product: Firefox → Core
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
You need to log in before you can comment on or make changes to this bug.