1248186 - Caret disappears in [contenteditable] element if I press Right arrow at the end of text

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 47, 32bit, ID 20160210071115
STR:
1.   Open the following "data:" url or click URL in the form above
>   data:text/html,<div class="declaration"><span></span><span class="value" contenteditable="">linear-gradient(to left, red, blue, green, yellow), url(test.png)</span> <span></span></div>
2.   Click on the text on that page  (preferably - between "s" and "t" in word "test")
3.A) Hold Right arrow for several seconds
3.B) Press Right arrow 6 times  (if you followed advice in Step 2)

AR:  Caret disappears. Looks like it just leaves [contenteditable] element
ER:  Caret should be displayed at the end of text in [contenteditable] element

This is regression from bug 669026. I'm not sure, so leaving "regressionwindow-wanted" keyword.
Regression range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c5b90ea7e475&tochange=f63a99195987

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Your suspected bug looks highly likely to be the culprit, yes.

Comment 2

[Jim Mathies [:jimm]]

jet, we'd like to get this fixed but we're getting it off the 47 tracking lists.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Fairly minor regression since 2011. It would be nice to fix but we are not going to track it.

Comment 5

[bikubi]

notes (and workaround):

• the contenteditable is not affected when it has a border
• also when when it is the last child, hence the . in this proof of concept:

data:text/html,<div><span contenteditable="" style="border: 1px solid black">edit me!</span>.</div>

Comment 6

[pommicket]

Attachment: Bug 1248186 - prevent focus loss at end of [contenteditable] r?emilio

Adjust nsFocusManager::GetSelectionLocation so that
it handles the case of moving to the end of a contenteditable
(previously only handled form controls)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1248186 - Preliminary clean-up of nsFocusManager::GetSelectionLocation. r=masayuki,pommicket

This patch shouldn't change behavior. It just removes a lot of noise
from that function.

In particular, it simplifies various conditions that can't happen, like
startNode being a text-node but a form control at the same time, or a
text-node and the root element.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6fd2f0219394
Preliminary clean-up of nsFocusManager::GetSelectionLocation. r=masayuki

Comment 9

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/6fd2f0219394

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Just landed the preparation patch.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/920e4f82b348
prevent focus loss at end of [contenteditable] r=masayuki

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/920e4f82b348

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:pommicket, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox119 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

This is a rather long-standing bug, we can let it ride the trains since the patch isn't super-trivial either.