5 ms·
This is not, as the other comments on this post are suggesting, an issue with Firefox intentionally ignoring platform conventions. Safari has the exact same beh
by ootachi 15y ago
This is not, as the other comments on this post are suggesting, an issue with Firefox intentionally ignoring platform conventions. Safari has the exact same behavior on the Mac as Firefox — Cmd+Left goes back, and Cmd+Right goes forward, except in textareas, when Cmd+Left goes to the beginning of the line and Cmd+Right goes to the end of the line. This is an ugly technical issue with XBL that is preventing Mozilla from implementing the behavior that they need to on the Mac for contenteditable areas.
The right target of blame here is XBL. XBL deserves criticism for being heavyweight, overengineered, and still not being flexible enough despite its enormous complexity. But this is not an issue of Mozilla intentionally ignoring platform conventions. They are trying to adopt the OS-native conventions and are facing limitations in their platform.
- thought_alarm 15y agoThe real problem is that Mozilla lacks a Mac OS X usability advocate with the authority to expedite sensible solutions to these kinds of problems. As we all know, the standard OS X shortcut for moving backward and forward is Cmd+[ and Cmd+]. The Cmd+Left/Right shortcut for moving backward/forward is decade-old cruft (even though Safari still conditionally supports it). If the Mozilla platform cannot handle supporting this cruft on top of the standard Cmd+Left/Right text editing behavior, then at the very least remove the cruft. Instead, the problem is allowed to linger for years and years as people bicker back and forth about what to do about it. That shouldn't be acceptable to anyone.
- ugh 15y agoYou mean the standard OS X shortcuts if you use a US keyboard, right? The shortcuts on a German keyboard (which does not have [ and ] keys) for back and forward are Shift-Cmd-Ö and Shif-Cmd-Ä (that’s using Safari), clearly inferior to Cmd-Left and Cmd-Right. Cmd-Left and Cmd-Right are necessary. (Google Chrome has actually Cmd-[ and Cmd-] as back and forward even with my German keyboard layout – which is quite dumb and shows that they don’t seem to care much for localization. Cmd-[ translates to Alt-Cmd-5 on a German keyboard.)
- silverlight 15y agoYou know it's an open source project and you could go ahead and add code yourself to support a more sensible shortcut on German keyboards, right? The sense of entitlement when it comes to something created and used freely, solely for the purpose of making the world better, sometimes simply astounds me.
- ugh 15y agoI can’t, actually, I’m not a developer, but that’s very much besides the point. I don’t think something should be protected from criticism just because it’s free. Just because it’s open source doesn’t mean I have to try to fix it before I’m allowed to criticize it. I can simply recognize shoddy workmanship and move on.
- LiveTheDream 15y agoCan others here verify if the bug exists for them? I just updated Firefox again and now I get different textarea behavior: 1. BROKEN: textarea in a Disqus comment editor (as suggested by a comment on the bugtracker). Cmd-left and Cmd-right go back and forward in browser history, unless there is no history in that direction, in which case they go the the beginning and end of the line. 2. BROKEN: gmail compose textarea. Cmd-left and Cmd-right do nothing at all. 3. WORKING: textarea for Hacker News commenting. Cmd-left and Cmd-right work as expected, moving to the beginning and end of the line regardless of browser history.
- carussell 15y agoThe title for the submission is wrong. This is not about textareas, but contenteditable elements (rich text editing).