1575576 - Emacs style keybindings on macOS don't work in elements with contenteditable attribute set

Status: RESOLVED DUPLICATE of bug 1502005

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

Description

[Ryan Kaskel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. Visit a site with an element that has the contenteditable attribute set.
2. Type Alt-F or Alt-B

Actual results:

The cursor did not move forward and backward by words as expected on macOS and doesn't respect DefaultKeyBinding.dict. This behaviour does happen on inputs and was fixed in 282097.

Expected results:

The element should respect DefaultKeyBinding.dict and move the cursor accordingly.

Comment 1

[Ryan Kaskel]

I've noticed that it only seems to be an issues for keybindings that begin with Option (ie the alt key).

For example, these don't work:

{
/* Additional Emacs bindings /
"~f" = "moveWordForward:"; / M-f /
"~b" = "moveWordBackward:"; / M-b /
"~<" = "moveToBeginningOfDocument:"; / M-< /
"~>" = "moveToEndOfDocument:"; / M-> /
"~v" = "pageUp:"; / M-v /
"~d" = "deleteWordForward:"; / M-d */
}

Comment 2

[Hani Yacoub, Desktop QA]

Could you please provide an example of a site with an element that has the contenteditable attribute set?
Thanks.

Comment 3

[Ryan Kaskel]

Sure, here is a page where you can verify the behaviour.

Here is a demo of the issues: https://ams3.digitaloceanspaces.com/lpd/bugs/bugzilla-1575576-demo.gif

Comment 4

[Hani Yacoub, Desktop QA]

Thanks for the demo and for the test page.
I couldn't manage to reproduce this issue, a character is insert in "Input/Textarea/Content editable" when i press "Option+f/b" and the cursor isn't moved forward and backward.
I'll assign "Core: Editor" component for it.

Comment 5

[Ryan Kaskel]

Thanks for trying to reproduce the issue.

You may need to create a DefaultKeyBinding.dict file in ~/Library/KeyBindings/. (Apple documentation is here)

The contents can be:

/* ~/Library/KeyBindings/DefaultKeyBinding.dict */

{
"~f" = "moveWordForward:"; /* M-f /
"~b" = "moveWordBackward:"; / M-b */
}

You might have to log out and in again although I can appreciate that's annoying to do.

This works in Google Chrome and Safari and in the input and textarea which is why I think it's a bug. I can see there is a TextInputListener::HandleEvent that seems to be involved in translating native key bindings so maybe that's not responding correctly when contenteditable is set?

I use Slack and they use contenteditable a lot which is how I came across this.

Comment 6

[Michael Stillwell]

I can reproduce this too.

Custom keybindings work as expected in:

• The URL bar
• Single line input fields
• <textareas> (such as the bugzilla comment field)

They do not work as expected in blocks that have contenteditable=true, such as comment fields on Reddit, Gmail. Chrome and Safari work as expected.

Comment 7

[Michael Stillwell]

Related (or a dupe):

https://bugzilla.mozilla.org/show_bug.cgi?id=1502005