1623717 - Home key does not work in inline contenteditable

Status: RESOLVED FIXED

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

Description

[Florine W. Dekker]

Attachment: test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Open the attachment, test.html. Select the contenteditable by clicking or pressing the Tab key. Now press the Home key.

The bug does not occur if the contenteditable is given the CSS attribute display: inline-block;.
The bug does not occur if the span that is in front of the contenteditable is removed.
The bug does not occur when pressing Shift + Home or Ctrl + Home.
The bug does not occur if the caret is on any line other than the contenteditable's first line; this can be done by selecting the contenteditable, pressing Shift + Enter, and then pressing Home.

Actual results:

Nothing happened.

Expected results:

The caret should move to the start of the current line in the contenteditable.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

Weird, Home key works on my machine on both Firefox 74 and Nightly, but instead End key (and also just ArrowRight to the end of the contenteditable) behaves wrong: the caret just disappears.

Comment 2

[Florine W. Dekker]

I uploaded the wrong version of test.html. The span with id suffix should be removed in order to match my bug report.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

I can see only one span there with no id. Could you check again? Removing the : suffix text still doesn't repro.

Comment 4

[Florine W. Dekker]

Attachment: test.html

My bad, I thought I had given them IDs. I've removed the suffix part and changed the display to inline instead of inline-block. This time I've double checked that it works ^^'

Comment 5

[Alice0775 White]

Attachment: bug

I can reprodce the issue on Nightly76.0a1 windows10.

Comment 6

[Florine W. Dekker]

(In reply to Alice0775 White from comment #5)

Created attachment 9134634 [details]
bug

I can reprodce the issue on Nightly76.0a1 windows10.

Nice! Also note that manually adding a newline inside the contenteditable (using Shift + Enter) changes things. For example, if you create two lines in the contenteditable in your first case, Home will only work on the second line, and End will only work on the first.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them)]

Confirmed here too, marking as such.

Comment 8

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 9

[Julien Wajsberg [:julienw]]

This is affecting Pernosco's filter and condition inputs. From Alice's bug attachment, the case with prefix+suffix applies to Pernosco.

Comment 10

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1623717 - Make sure selection offset remains within inline editing host r=emilio

Depends on D107119

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7fbe32c35b5
Make sure selection offset remains within inline editing host r=emilio

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/28463 for changes under testing/web-platform/tests

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/d7fbe32c35b5

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot