Ctrl+Shift+Right arrow doesn't select last word in contenteditable element

RESOLVED FIXED in Firefox 45

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: piotr.kwiatkowski.poz, Assigned: jfkthame, NeedInfo)

Tracking

({regression})

36 Branch
mozilla46
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 wontfix, firefox43 wontfix, firefox44 affected, firefox45 fixed, firefox46 fixed, firefox-esr38 wontfix, firefox-esr45 fixed)

Details

()

Attachments

(2 attachments)

Reporter

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

Try to create empty html file. Insert a div with contenteditable attribute set to "true".
 After created div please insert some html node, it can be span 
Write some random text in contenteditable div. Try to select subsequent words with ctrl+alt+right arrow key shortcut and deselect them in ctrl+alt+left arrow.
You have this situation recreated in simple js fiddle:
https://jsfiddle.net/yszqhoz3/1/


Actual results:

last word cannot be selected with ctrl+alt+right arrow


Expected results:

last word should be properly selected just as previous words

Comment 1

4 years ago
Also ran into this defect, but using ctrl+shift+right arrow, not ctrl+alt+right arrow, could be that "alt" is just a typo.

Comment 2

4 years ago
Same issue here and as was mentioned <ctrl> + <right arrow> (of course + <shift> for selecting text - same behavior), not <alt>.

Seems that this is hapening only in some specific html/js text elements.
For example in this post (when I'm creating it) is everything OK, but for example gmail - compose mail there is visible this bug - last word not possible to select.

FF version 39.0.3 on Windows 7 Enterprise.

Comment 3

4 years ago
I have experience the same, useing <ctrl> + <shift> + <right arrow> the last word is not selected on a div with contenteditable set on true unless just after the closing div I have a textarea and is not hidden.
In this case selection is not working.
<span><div contenteditable="true">text to select</div><textarea style="display: none;"></textarea></span>
In this case selection is working fine. Also if I add height:0px or opacity:0 on textarea.
<span><div contenteditable="true">text to select</div><textarea></textarea></span>

I'm having this problem in FF version 41.0.2 on Windows 7. Same FF version on linux is not generating this problem.
Hello all, is this still a problem for you all? 

I tried reproducing on the newest nightly build 45.0a1 build id 20151112030238 on windows 8.1 and 10.
Flags: needinfo?(piotr.kwiatkowski.poz)

Comment 5

4 years ago
Hey Justin,

I've tried the latest nightly build 45.0a1 on Win7 and Win 8.1 and the problem is still there.
Ok. I will pass this up to a developer.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

4 years ago
More generally:   Ctrl+Right doesn't move cursor to the very end of last word in [contenteditable]
This issue is presented for a LONG time on vk.com (russian social network; 75+ million users)
Component: Untriaged → Editor
Flags: needinfo?(piotr.kwiatkowski.poz)
Product: Firefox → Core
Summary: ctrl alt right arrow doesn't select last word in contenteditable → Ctrl+Shift+Right arrow doesn't select last word in contenteditable element

Updated

4 years ago
See Also: → 1137973

Comment 8

4 years ago
Regression range: 
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be4ba3d5ca9a&tochange=74edfbf0e6a3
This is not very precise, and I heard that some people are able to continue bisection on local builds, so I'm leaving keyword "regressionwindow-wanted"
Assignee

Comment 10

3 years ago
The problem here shows up only on Windows because of two factors: (a) it depends on layout.word_select.eat_space_to_next_word being set to true, which is (by default) only the case on Windows; and (b) it occurs only if the keystrokes are mapped to the new physically-oriented cmd_{Move,Select}* commands, which are used on Windows, whereas for Cocoa and Gtk the NativeKeyBindings code in widget/ maps keystrokes to the logical cmd_selectWordNext etc.

What happens is that when we try to select the last word, the nsFrameSelection::MoveCaret call fails because it is trying to move to the beginning of the next word (i.e. "eating" the intervening space), but there is no "next word" to be found.

On platforms where we're generating cmd_selectWordNext, this is handled by PresShell::WordMove(), which sees the failure and falls back to CompleteMove() to advance to the end of the text, but PhysicalMove doesn't handle this and so the select (or move) command simply fails.
Flags: needinfo?(jfkthame)
Assignee

Comment 11

3 years ago
Here's a testcase that should exhibit the failure across all platforms.
Attachment #8703726 - Flags: review?(roc)
Assignee

Updated

3 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED

Updated

3 years ago
Duplicate of this bug: 1137973

Updated

3 years ago
Duplicate of this bug: 1130997
Assignee

Comment 16

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7f12e55b099e582b4bf2aba52be817d07f883b61
Bug 1153237 - nsFrameSelection::PhysicalMove should fall back to CompleteMove if an intra-line move fails to execute completely. r=roc

https://hg.mozilla.org/integration/mozilla-inbound/rev/c206ee0a4809e515294aee998fa0b249a7fe1a16
Bug 1153237 - Testcase for failure to select last word in a contenteditable div when using physical select-by-word command. r=roc
Assignee

Comment 17

3 years ago
Comment on attachment 8703727 [details] [diff] [review]
nsFrameSelection::PhysicalMove should fall back to CompleteMove if an intra-line move fails to execute completely

Approval Request Comment
[Feature/regressing bug #]: bug 1077515

[User impact if declined]: For Windows users, ctrl-rightarrow fails to move cursor or extend selection across last word of an editable element in some cases (see also description in duplicate bugs).

[Describe test coverage new/current, TreeHerder]: New mochitest landed along with the patch.

[Risks and why]: Minimal risk, patch just adds fallback handling for a failure case that we're currently leaving unhandled.

[String/UUID change made/needed]: n/a
Attachment #8703727 - Flags: approval-mozilla-beta?
Attachment #8703727 - Flags: approval-mozilla-aurora?
Piotr, could you please verify this issue is fixed as expected on Nightly build from 1/5/2016 or 1/6/2016? Thanks!
Flags: needinfo?(piotr.kwiatkowski.poz)
Assignee

Comment 19

3 years ago
It won't be fixed on Nightly 1/5, as the patch hasn't yet merged to m-c AFAICS. I hope it'll get merged shortly, in time for 1/6.

Comment 20

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7f12e55b099e
https://hg.mozilla.org/mozilla-central/rev/c206ee0a4809
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Comment on attachment 8703727 [details] [diff] [review]
nsFrameSelection::PhysicalMove should fall back to CompleteMove if an intra-line move fails to execute completely

Taking it in Aurora45. Denying for Beta44 as this issue has been around for past two releases and this point forward in Beta44 cycle, I am only taking fixes that improve stability or are critical regressions.
Attachment #8703727 - Flags: approval-mozilla-beta?
Attachment #8703727 - Flags: approval-mozilla-beta-
Attachment #8703727 - Flags: approval-mozilla-aurora?
Attachment #8703727 - Flags: approval-mozilla-aurora+

Updated

3 years ago
Duplicate of this bug: 1242386

Updated

3 years ago
Depends on: 1248128

Updated

3 years ago
Depends on: 1248185

Updated

3 years ago
See Also: → 1249444

Updated

3 years ago
See Also: → 1257119
I'm porting the test here to mochitest-plain for bug 1269209 so that it runs on e10s too.  Would it be fine to replace the use of commandDispatcher here with synthesizeKey?  According to comment 10, this will still test the original bug on Windows.  Or, do you know of another way of testing it that works in a plain mochitest?
Flags: needinfo?(jfkthame)
Never mind, we need to get arbitrary commands working in plain mochitests for other tests anyway.
Flags: needinfo?(jfkthame)

Updated

2 years ago
See Also: → 1328026
You need to log in before you can comment on or make changes to this bug.