Open Bug 1249444 Opened 5 years ago Updated 4 years ago

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

Categories

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

45 Branch
defect

Tracking

()

Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- fix-optional
firefox50 --- fix-optional
firefox51 --- fix-optional

People

(Reporter: arni2033, Assigned: jfkthame)

References

(Depends on 1 open bug)

Details

(Keywords: regression, Whiteboard: dom-triaged btpp-fixnow)

Attachments

(1 file)

>>>   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
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.
Assignee: nobody → jfkthame
Whiteboard: dom-triaged btpp-fixnow
editor related regression in jan 2016, should we track this?
Flags: needinfo?(bugs)
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
Summary: Ctrl+Left arrow doesn't move caret before first word in contenteditable element → Ctrl+Right (left) arrow doesn't move caret in the end (beginning) of contenteditable element
Version: Trunk → 45 Branch
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 :)
Flags: needinfo?(arni2033)
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.
Depends on: 1277113
Flags: needinfo?(bugs)
(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.
Flags: needinfo?(arni2033)
You need to log in before you can comment on or make changes to this bug.