1249444 - Ctrl+Right (left) arrow doesn't move caret in the end (beginning) of contenteditable element

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[arni2033]

Attachment: testcase 1 - Ctrl+Left doesn't move caret before first word in contenteditable.html

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160218030349
STR:
1. Open attached "testcase 1" or http://jsbin.com/bisahaqote/edit?html,css,output (from bug 1143742)
2. Click between the first string "gradient(" on page and the first string "to left" on page.
3. Press Ctrl+Left   [caret moves to the beginning of the first string "gradient(" on page).
4. Press Ctrl+Left

AR:  After Step 4 nothing happens
ER:  Caret should move to the beginning of the first string "linear-" on page.

This didn't work before bug 1153237 was fixed, then it worked nice for a while, until bug 1248128.

This is regression from bug 1248128. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4d75bd6fd234c402084b1683034dd1b71adec555&tochange=ee60dc3d06556a23222a8c25a93aaa818ccca9b9

Comment 1

[Jonathan Kew [:jfkthame]]

Ah, so this is a move-word-left variation of bug 1153237 (-right).

The patch in bug 1153237 "accidentally" fixed this because it tried to handle failures in a somewhat general way, but it was too eager and led to some regressions. Bug 1248128 made it precisely focus on the originally-reported bug, but that made it no longer cover this similar-but-unnoticed case.

Comment 2

[Jim Mathies [:jimm]]

editor related regression in jan 2016, should we track this?

Comment 3

[arni2033]

Ctrl+Left doesn't work in rule values in the testcase.
Ctrl+Right doesn't work in rule names in the testcase.
Bug 1248128 has (partially?) broken the fix in bug 1153237. So bug 1153237 was never fixed on Release.
This is "pseudo" regression, what means that functionality was fixed, then broken again after ~1 month

Comment 4

[Andrew Overholt [:overholt]]

Arni, do you think it'd be possible to turn the test case you have here into a mochitest (one of the test frameworks we use, in case you didn't know)? Feel free to say no but it would help areas like this that are undertested :)

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

While this is a valid issue, it is not a new regression in Fx47. This regressed in Fx45 and we are 5 days away from go-live so it might be too late to fix this in 47.

Comment 6

[arni2033]

(In reply to Andrew Overholt [:overholt] from comment #4)
> Arni, do you think it'd be possible to turn the test case you have here into a mochitest?
Well... I originally stole the testcase from <:pbro> - bug 1143742 comment 4 (just FYI)
When I last checked, I haven't found a clear manual on "creating mochitest" in 15 minutes, so this is now in the end of my TO-DO list (saving some bugs locally has top priority for me), which means that you can either wait until I find time to look at this closely (~1 month) or ask somebody else.