995136 - cmd-left in a contenteditable should go to the start of the line in OSX

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Le Roux Bodenstein]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Here's a test case: http://codepen.io/lerouxb/pen/DCElm

Open that URL in Firefox on OSX.

Make sure you followed the link there so that there is a previous page to go back to. Maybe browse to the details screen from the editor so there is a previous page.

Type some text in the text input field. Hit cmd-left arrow and the cursor will move to the start of the text input field just like it should. 

Now focus the contenteditable div below that text input. Hit cmd-left arrow again. 


Actual results:

Firefox will browse to the previous page instead of moving the cursor to the start of the line.




Expected results:

The standard OSX behavior is documented here: http://support.apple.com/kb/ht1343

(For Windows and Linux folks: Mac keyboards don't have HOME and END keys. You get the same behavior by hitting cmd-left or cmd-right. This is akin to mapping the HOME and END keys to browse back and forward.)

The text input cursor should be moved to the start of the line. cmd-left should NOT browse to the previous page, especially not while something that's capable of receiving text input is focused.

Other browsers get this right and Firefox gets this right for other types of text input fields. Just not contenteditable.

My current workaround is to just suppress those keys in contenteditables which means there are no keyboard shortcuts to jump around in text. This makes text editing infuriating, but at least not as bad as browsing to the previous page and either losing all your work or getting a popup confirmation dialog.

Comment 1

[Vlad Bacia-Mociran [:VladB]]

I didn't managed to reproduce this issue on the latest release(43.0.4) nor the latest Nightly(46.0a1).

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160111030207

Can you please try to reproduce this on the latest release(43.0.4) and latest Nightly(46.0a1) and provide the results?
When doing this, you could create a new clean Firefox profile, or maybe test in safe mode, as some of this issues may be caused by third party installed addons or custom settings
(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thank you,
Vlad

Comment 2

[Le Roux Bodenstein]

I can't recreate it in recent versions of Firefox anymore. (Not with that test, anyway)

Looks like it has been fixed at some stage. Marking as resolved.