Closed Bug 1153237 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: DOM: Selection, defect)

36 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla46
Tracking Status
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 --- affected
firefox45 --- fixed
firefox46 --- fixed
firefox-esr38 --- wontfix
firefox-esr45 --- fixed

People

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

References

()

Details

(Keywords: regression)

Attachments

(2 files)

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
Also ran into this defect, but using ctrl+shift+right arrow, not ctrl+alt+right arrow, could be that "alt" is just a typo.
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.
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)
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
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
See Also: → 1137973
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"
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)
Here's a testcase that should exhibit the failure across all platforms.
Attachment #8703726 - Flags: review?(roc)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Duplicate of this bug: 1137973
Duplicate of this bug: 1130997
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
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)
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 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+
Duplicate of this bug: 1242386
Depends on: 1248128
Depends on: 1248185
See Also: → 1249444
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)
See Also: → 1328026
You need to log in before you can comment on or make changes to this bug.