Cmd/Command+Left/Right does not move caret in Gmail compose message

RESOLVED FIXED

Status

RESOLVED FIXED
12 years ago
4 years ago

People

(Reporter: jruderman, Assigned: Ehsan)

Tracking

Firefox Tracking Flags

(firefox24 affected, firefox25 affected, firefox26 affected, firefox27 affected, firefox-esr17 affected, firefox-esr24 affected)

Details

(Whiteboard: [country-all][sitewait] [good first verify], URL)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060608 Minefield/3.0a1

Steps to reproduce:
1. Log into Gmail.
2. Click "Compose Mail".
3. Click "rich formatting" above the message body field (unless you're already in that mode).
4. Type "xyz" into the message body.
5. Press Cmd+Left.

Result: nothing happens when I press Cmd+Left.

Expected: the caret should move to the beginning of the line (before the "x").

Notes:
* Cmd+right works fine; only Cmd+left is broken.
* Cmd+left works if I go back to plain text mode.
* Cmd+left works in http://www.squarefree.com/contenteditable.html, so this bug isn't as simple as "Cmd+left is broken in designMode".  I haven't tried very hard to make a reduced testcase because Gmail intimidates me.
Cmd+left does not work as expected in designMode, when the back button is enabled: it just goes back, as on a "normal" page. I suspect this is the underlying cause of this bug (although in Gmail, cmd+left doesn't actually go back, perhaps because Gmail intercepts and cancels the action).

To reproduce:
- Click the link in comment #0 so that it will open in the current tab/window.
- (optionally) verify that you're in design mode by moving the caret back and forth
- Press cmd+left, and notice you're back at this page.

The same is true for cmd+right: It goes forward (instead of moving the caret to the end of line) if "Forward" is available.

Jesse - do you want to morph this bug to describe the issue above, or should I report a separate bug (and make this one depend on it)?
(Reporter)

Comment 2

12 years ago
Please make that a new bug blocking this one, because I don't know whether/how Gmail blocks Cmd+Left for Back while focus is in that editing frame.

Updated

12 years ago
Depends on: 342564
Filed bug 342564 for the issue described in comment #1.
Actually, this is unrelated to bug 342564: it's reproducible in builds from when the cmd+arrow back/forward shortcuts were removed (April-June 2005).
No longer depends on: 342564
QA Contact: editor

Comment 5

11 years ago
I've experienced this for a long time and it drives me nuts.  It still occurs in FF3b5.  Are there any plans to fix it?

Comment 6

10 years ago
+1 on Henry's comment. I love FF3, the Awesome Bar in particular, but I've now switched to using Safari with Gmail because that's where it behaves correctly! Please fix!
(Reporter)

Updated

10 years ago
Duplicate of this bug: 438275

Comment 8

10 years ago
There is a tool called "Firefox keyfixer" that gets around this problem by remapping the "cmd_beginLine" and "cmd_endLine" accelerators to the home/end keys to match behavior in Windows.  (see http://blog.mvballtech.com/2008/05/can-firefox-keyconfig-fix-homeend.html)

Keyfixer is a patch utility that modifies the Firefox configuration file named platformHTMLbindings.xml (kept inside the zip file named /Applications/Firefox.app/Contents/MacOS/chrome/toolkit.jar) with the appropriate keyboard shortcuts. For example, these are the lines that change Home/End to go to the beginning/end of the current line instead of top/bottom of current edit window.


<!-- Additions to fix home/end -->
<handler event="keypress" keycode="VK_HOME" command="cmd_beginLine"/>
<handler event="keypress" keycode="VK_END" command="cmd_endLine"/>
<handler event="keypress" keycode="VK_HOME" modifiers="shift" command="cmd_selectBeginLine"/>
<handler event="keypress" keycode="VK_END" modifiers="shift" command="cmd_selectEndLine"/>

My guess is that GMail is explicitly grabbing the 'Cmd-Arrow' key combination and eating it -- not the cmd_beginLine/cmd_endLine handlers.

I switched to Safari for a while to get around this issue, but have most recently switched to keyfixer with Firefox because Safari bugs me in other ways.  However, it would be nice if this were fixed so that I don't (necessarily) have to use keyfixer.

Comment 9

10 years ago
It looks like that simply makes it behave like Firefox on Windows, which to me is even worse behaviour. All I want is for it to act like everything else on Mac.

Comment 10

10 years ago
Josh: Yes -- the Firefox keyfixer utility does make Firefox behave like the Windows version.  The point of the comment was not to extol the virtues of one key binding versus another, but to show a work-around for this issue.  I expect you could map 'Alt-Left Arrow' to cmd_beginLine instead of 'Home' to make it a little more Mac-like.  In any case, the current (preferred) mapping of 'Cmd-Left Arrow' to cmd_beginLine doesn't work, so anything other key binding is better in that it provides _some_ way to execute cmd_beginLine.

Does Google know about this problem?  I expect they should have some resources to fix it, especially if it improves the Google experience for Mac users.  Google fully supports both Firefox and Safari on most of their products.  It's quite possible that this is a quirk due to Google's Javascript code in GMail (although it does work correctly on Safari...).
Duplicate of this bug: 457620
Summary: Cmd+Left does not move caret at Gmail in rich formatting mode → Cmd/Command+Left/Right does not move caret at Gmail in rich formatting mode

Comment 12

10 years ago
Havin the same issue with Gmail. Firefox does not correctly recognize command+left arrow to move the caret to the beginning of the line. I use Firefox 3.1 beta - same problem.

Updated

9 years ago
Duplicate of this bug: 502610

Comment 14

9 years ago
This has become even more critical with the release of Google Wave. Surely we can look at changing the core firefox bindings?

Comment 15

9 years ago
It seems to me that this issue is a little overlooked, with literally thousands of users potentially suffering in silence. A lot of us mac users love Firefox but have to use Safari due to this major annoyance.

It would be great if someone upstream could contact Google about this so that we at least know who should take on the burden of fixing the issue?

From what I've seen thou it could be FF's "fault", as the widely used TinyMCE also exhibits problems (Cmd-left = back rather than beginning of line).
(Reporter)

Comment 16

9 years ago
Sounds like TinyMCE is hitting bug 342564, which is definitely a Firefox bug.

The problem with Gmail seems to be different, since it happens even if you don't have a page to go Back to.  Maybe it's due to Google attempting to work around bug 342564?

Comment 17

9 years ago
I see this in Google Docs, as well. Doesn't seem to be the same issue as bug 342564. If that's the case, should this be set to NEW?

Comment 18

8 years ago
Its worse than just not moving the caret. I most forms it actually causes the page to navigate back -- losing everything I typed in the form!! I've lost more forum posts this way than anything else in the last year.
(Reporter)

Comment 19

8 years ago
Indeed, but that's bug 289384.
(Reporter)

Updated

8 years ago
Duplicate of this bug: 405503
(Assignee)

Updated

8 years ago
Assignee: nobody → ehsan
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Whiteboard: [post-2.0]

Comment 21

7 years ago
In Firefox 4.0.1 this bug hasn't been resolved. It has been duplicated in other bug reports, so that means many people are reporting about it, with countless people being affected.
(Reporter)

Comment 22

7 years ago
I think this is something Gmail needs to fix. But they're probably waiting for us to fix bug 289384.
(Assignee)

Comment 23

7 years ago
(In reply to comment #22)
> I think this is something Gmail needs to fix. But they're probably waiting
> for us to fix bug 289384.

And unfortunately as we learned the hard way, fixing that bug is not trivial either :(
Any reason to not dupe this against bug 289384?
(Reporter)

Comment 25

7 years ago
Yes, see comment 16.  Gmail's workaround for bug 289384 (which only happens when there's a page to go back to) breaks the shortcut in all cases.

Comment 26

7 years ago
It's worth noting that this bug is something which can be worked around at the webapp level.  The editor for Novell Vibe specifically binds Cmd-Left / Cmd-Right to the Home / End actions, respectively.  This has the dual effect of overriding the page back / forward action as well as making the combos behave the way one would expect in an editor.  I'm not sure why Gmail hasn't done something similar...
(Assignee)

Comment 27

7 years ago
This _might_ be an evang bug once bug 289384 gets fixed...
Depends on: 289384
Dietrich: Can you fix this? Who do I need to bribe? This is driving me crazy. It's been broken since 2006? Gottel himmel!

Comment 29

6 years ago
Any updates on this bug?

Comment 30

6 years ago
Still no solutions? This bug is still not solved after more than 6 years.

Comment 31

6 years ago
Until this bug will be solved one can use the Emacs Key Bindings:

go to start of line
Ctrl-A
remember by: A = Start of alphabet

go to end of line
Ctrl-E
remember by: E = End

Comment 32

6 years ago
This related not only "rich formatting" mode! It's actualy related to ANY input field. I'm using Firefox 19.0 on MacOS 10.8.
(Reporter)

Comment 33

6 years ago
Yeah, a few months ago Gmail changed their "plain text" compose mode to also use contenteditable.
Summary: Cmd/Command+Left/Right does not move caret at Gmail in rich formatting mode → Cmd/Command+Left/Right does not move caret in Gmail compose message
You probably won't care, but this very bug is what prevents me from completely switching back from Chrome.

Firefox is now once again ahead or good enough in all the domains that matter for me, except for this.

Comment 35

5 years ago
This is also driving me nuts.

And regarding the Emacs Key Bindings: if the search box is opened, Ctrl-A does not work as expected...

Comment 36

5 years ago
+1

This bug is brutal. Really makes typing emails on FF in Gmail much worse.

I didn't realize how important that keyboard shortcut was, until I no longer had it.

Comment 37

5 years ago
Found a workaround: install the "keyconfig" add-on (http://mozilla.dorando.at/keyconfig.xpi).

The go to Tools | keyconfig and reset those shortcuts.

At first I thought keyconfig wouldn't work anymore (since it is quite old), but it still does its magic.

I still believe this bug should be fixed, though. I spent some time finding this fix. In fact I even tried (without success) to start using Safari, just because of this issue!
I just tried keyconfig.xpi, it doesn't seem to work here.

Is there anything else to do beside changing the setting in the Tools > Keyconfig window? I tried restarting FF, it still doesn't work.

OS X 10.8, FF 22.

Comment 39

5 years ago
keyconfig.xpi add-on also doesn't work for me. And even if it did, from what I understand, it would remove Cmd+Left/Right default's behaviour which is not what it should do. What it should do is just work as Home/End when focus is in Rich Textboxes (as it does in other textboxes) and work as Back/Fwd when it's not.

I'm Google Chrome instead of FF just because of this issue.
Duplicate of this bug: 906699
Shift-command-right should also move to the end of the line and select text up until the EOL as described in bug 906699.

Comment 42

5 years ago
This bug has been around for YEARS, literally.

When are you going to fix it? GMail is a major thing, and now it is very painful and inefficient to use it.

Please fix this.
(Assignee)

Comment 43

5 years ago
(In reply to comment #42)
> This bug has been around for YEARS, literally.
> 
> When are you going to fix it? GMail is a major thing, and now it is very
> painful and inefficient to use it.
> 
> Please fix this.

Have you read the previous comments where we tried to fix it?  These kinds of comments on bugzilla don't really help us fix things faster, and it just makes our efforts feel under-appreciated.

Comment 44

5 years ago
Sorry, it is not about effort, it's about effect. A customer appreciates effects.
I know this might sound harsh, but that's the way it is, I should know, I build software myself. I don't get any credit for effort alone.

Other than that, what user feedback would you expect for a bug that is _8 years_ old? It's obvious people are going to get angry. Which is a sign that they actually care about Firefox and want to stick with it. Me, I cannot take FF seriously if stuff like this happens, and doesn't get fixed for a decade. In an age where people try to build whole OSes composed of webapps, having such a bug really sets you back compared to competition.
(Assignee)

Comment 45

5 years ago
(In reply to comment #44)
> Sorry, it is not about effort, it's about effect. A customer appreciates
> effects.
> I know this might sound harsh, but that's the way it is, I should know, I build
> software myself. I don't get any credit for effort alone.
> 
> Other than that, what user feedback would you expect for a bug that is _8
> years_ old? It's obvious people are going to get angry. Which is a sign that
> they actually care about Firefox and want to stick with it. Me, I cannot take
> FF seriously if stuff like this happens, and doesn't get fixed for a decade. In
> an age where people try to build whole OSes composed of webapps, having such a
> bug really sets you back compared to competition.

You're more than welcome to take these complaints elsewhere.  Adding them to bugs actually makes the process of fixing the bug more difficult, and is against our etiquette: <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.  Please stop doing that.  Thanks!

Comment 46

5 years ago
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #45)

> You're more than welcome to take these complaints elsewhere.  Adding them to
> bugs actually makes the process of fixing the bug more difficult,

How exactly do they make the fixing process more difficult? 
You mean that by reading and answering that comment it will take 10 years and 30 minutes to fix the bug, rather than just 10 years sharp?

> and is against our etiquette:
> <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.  Please stop
> doing that.  Thanks!

It is totally not against your etiquette, actually. 
It is very clearly stated there that "constant and intense" critique is what you expect from us, as long as (I quote verbatim) "you attack things, not people. Examples of things include: interfaces, algorithms, and schedules."

Here everybody seems to have issues with the "schedule". And understandably so.
A time-scale of several weeks to fix a deal-breaker bug affecting such a major service as Gmail would be annoying and disappointing. 
A time-scale of decades is downright in the realm of surreal.

In case it is not clear: everybody here really really wants to use Firefox, but is broken. Please help us continuing using your product!

Comment 47

5 years ago
Hello! Just wanted to chime in. This bug drives me nuts as well.

Is there a place where this bug is discussed more in-depth by developers? I'm not much of a programmer, but I'd do my best to lend a hand if someone could point me in the right direction. I'm sure others would do the same.

Obviously this bug is complicated and difficult to fix. Could we get an explanation of the hurdles in the way of a solution? Maybe then some aspiring developer could be better able to have a go at it.

I LOVE Firefox. Thanks to all of its developers and contributors for all your hard work!

Comment 48

5 years ago
Not sure whether this can help, but I found out that Cmd+Left/Right DOES work in the subject field. Unfortunately it DOES NOT work in the message body. 

This is very puzzling but maybe might provide some useful clue?
Please solve this bug!
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox-esr17: --- → affected
status-firefox-esr24: --- → affected
Hardware: PowerPC → All
Duplicate of this bug: 899275

Comment 50

5 years ago
A new version of Firefox is out. And this serious problem still remains unsolved.
How long should we wait before it is fixed? Another decade? 

And also: can we please have some feedback? Is somebody working on this? What are the problems? Why nobody seems to care? This affects basically a huge number of FF users on MacOSX.

Updated

5 years ago
Duplicate of this bug: 653025

Comment 52

5 years ago
This is a pretty disruptive issue as it makes you lose everything you type on a form, and for some forms that could be a lot. I noticed this issue happens on our own internal applications, which I write. The editor I use on our applications is the WYMeditor (which works well on Safari):
https://github.com/wymeditor/wymeditor

If you try the examples you will notice the issue. So I looked into what WYMeditor does:
WYMeditor is a jQuery plugin that replaces a textarea with a designMode iframe surrounded by an editor skin and editor controls/buttons...
More here: http://wymeditor.readthedocs.org/en/latest/wymeditor_development/wymeditor_architecture.html

Hopefully this additional information can help.
(Assignee)

Comment 53

5 years ago
Guys, we understand the severity of this issue.  As you can see by reading this bug, I have tried pretty much everything that I could think of but none of that has worked so far.  Please note that adding comments which do not help in fixing this bug on our side will only make the bug larger, more difficult to read and therefore more difficult to fix.

Thanks!
The technical discussion actually happened on the related bug 289384.

If you only read this discussion, you get the impression that the bug is being overlooked, whereas the other thread reveals that you really tried hard to fix the general issue, to no avail.

Maybe you could ping other devs to look into it?

Comment 55

5 years ago
(In reply to Pierre-Yves Gérardy from comment #54)
> The technical discussion actually happened on the related bug 289384.
> 
> If you only read this discussion, you get the impression that the bug is
> being overlooked, whereas the other thread reveals that you really tried
> hard to fix the general issue, to no avail.
> 
> Maybe you could ping other devs to look into it?

And yet Google Chrome can do it...
The way events are handled in FF is obviously very complex.

There was a fix for the parent problem, but it caused regressions (the scroll bar stopped working in some rich text editor), and it had to be reversed. Fixing this bug probably requires an overhaul of event handling, and it's not a small task.

I didn't look into it, but I wouldn't be surprised that Google disables the shortcuts on purpose for FF on the Mac, to compensate for bug 289284.
(Assignee)

Comment 57

5 years ago
Yeah, bug 289284 is most likely the root cause behind this bug, but even after fixing that bug there might still be problems left to be resolved here.

Comment 58

5 years ago
> I didn't look into it, but I wouldn't be surprised that Google disables the
> shortcuts on purpose for FF on the Mac, to compensate for bug 289284.

No, eg. cmd+k works in FF on Mac.

Comment 59

5 years ago
> Fixing this bug probably requires an overhaul of event handling,
> and it's not a small task.

Sounds good. So, since it took 8 years to identify the problem, can we look forward to a solution by the end of the next decade, or am I being too optimistic here?
(Assignee)

Comment 60

5 years ago
(In reply to comment #59)
> > Fixing this bug probably requires an overhaul of event handling,
> > and it's not a small task.
> 
> Sounds good. So, since it took 8 years to identify the problem, can we look
> forward to a solution by the end of the next decade, or am I being too
> optimistic here?

You are not being helpful here.  Please stop commenting on this bug unless you're proposing a technical solution for a fix.  Thanks!

Comment 61

5 years ago
> You are not being helpful here.  Please stop commenting on this bug unless
> you're proposing a technical solution for a fix.  Thanks!

You are not being helpful here.  Please fix this bug before my grandchildren reach their retirement age.  Thanks!

Comment 62

5 years ago
@Luther Blisset: plonk.

Thanks to everyone working to solve either this or the other issues :-)

Would it be viable to delegate the resolution of this issue to an addon instead of rewriting the event handling layer?
Like detecting if the focus is in Gmail's rich text editor and temporarily turning off or proxy-ing the proper shortcuts?
As a requirement for the previous question, is the event handling layer "scriptable" by addons?
(Assignee)

Comment 63

5 years ago
I would expect doing that to cause more problems than it would solve.  :/

Comment 64

5 years ago
In case one would be interested, there is an easy workaround:
Install keyconfig addon http://mozilla.dorando.at/keyconfig.xpi
With this addon, you'll be able to find the CMD left/right arrow and disable it.

I can't thing of all the new things I'll have time to do with all the free time not retyping my forms will give me !
(Assignee)

Comment 65

5 years ago
Note that bug 289284 is very close to getting fixed.
(Assignee)

Comment 66

5 years ago
(In reply to comment #65)
> Note that bug 289284 is very close to getting fixed.

Er, that was meant to be bug 289384.
Blocks: 950073
Whiteboard: [post-2.0] → [post-2.0][triage]
(Assignee)

Comment 67

5 years ago
Now that bug 289384 is fixed, I reached out to the Gmail team to see if we the workaround can be removed on their side for Firefox 29.
(Assignee)

Updated

5 years ago
Whiteboard: [post-2.0][triage] → [triage]
(Assignee)

Updated

5 years ago
Component: Editor → English US
Product: Core → Tech Evangelism
(Assignee)

Updated

5 years ago
No longer blocks: 950073
Whiteboard: [triage]

Comment 68

5 years ago
Workaround for this problem: 
1. Install https://pqrs.org/macosx/keyremap4macbook/index.html.en
2. Use the following for the private.xml file:
<?xml version="1.0"?>
<root>
  <item>
    <name>Cmd Arrow Fix for Firefox</name>
    <identifier>private.cmd_arrow_fix_for_firefox</identifier>
    <autogen>
      __KeyToKey__
      KeyCode::CURSOR_LEFT, ModifierFlag::COMMAND_L | ModifierFlag::NONE,
      KeyCode::A, ModifierFlag::CONTROL_L
    </autogen>
    <autogen>
      __KeyToKey__
      KeyCode::CURSOR_RIGHT, ModifierFlag::COMMAND_L | ModifierFlag::NONE,
      KeyCode::E, ModifierFlag::CONTROL_L
    </autogen>
  </item>
</root>

Comment 69

5 years ago
You can also add the line:
    <only>FIREFOX</only>
right after the <identifier> line.
This will make the shortcut work only for Firefox

Comment 70

4 years ago
Is there anything we as a community can do to accelerate the removal of the Gmail workaround from Google like you said? Sending bug reports to them etc?
(Assignee)

Comment 71

4 years ago
(In reply to comment #70)
> Is there anything we as a community can do to accelerate the removal of the
> Gmail workaround from Google like you said? Sending bug reports to them etc?

Yes, please ask Gmail to remove their workaround which is no longer needed.  I have contacted them but have never heard back from them.
(Assignee)

Comment 72

4 years ago
Actually, a Gmail contact just confirmed that this is on their todo list, so hopefully it will be fixed in the near future!
Component: English US → Desktop
Whiteboard: [country-all][sitewait]

Comment 73

4 years ago
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #72)
> Actually, a Gmail contact just confirmed that this is on their todo list, so
> hopefully it will be fixed in the near future!

It's been over one month since your comment, is there any update on this? 

Thanks!
(Assignee)

Comment 74

4 years ago
(In reply to comment #73)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #72)
> > Actually, a Gmail contact just confirmed that this is on their todo list, so
> > hopefully it will be fixed in the near future!
> 
> It's been over one month since your comment, is there any update on this? 

Thanks for the reminder.  I asked my contact again.  Will report back once I hear from them.
(Assignee)

Comment 75

4 years ago
I heard back, they said they are hoping to get to this issue within the next month or two.

Updated

4 years ago
Duplicate of this bug: 1012439

Comment 77

4 years ago
(In reply to Emerson from comment #68)
> Workaround for this problem: 
> 1. Install https://pqrs.org/macosx/keyremap4macbook/index.html.en
> 2. Use the following for the private.xml file:
> <?xml version="1.0"?>
> <root>
>   <item>
>     <name>Cmd Arrow Fix for Firefox</name>
>     <identifier>private.cmd_arrow_fix_for_firefox</identifier>
>     <autogen>
>       __KeyToKey__
>       KeyCode::CURSOR_LEFT, ModifierFlag::COMMAND_L | ModifierFlag::NONE,
>       KeyCode::A, ModifierFlag::CONTROL_L
>     </autogen>
>     <autogen>
>       __KeyToKey__
>       KeyCode::CURSOR_RIGHT, ModifierFlag::COMMAND_L | ModifierFlag::NONE,
>       KeyCode::E, ModifierFlag::CONTROL_L
>     </autogen>
>   </item>
> </root>

Thank you. Solved the issue for me until it is solved permanently.
(Assignee)

Comment 78

4 years ago
This is now fixed on the Gmail side.  You may need to refresh Gmail to get the fix.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 79

4 years ago
Bummer, we were waiting for tomorrow's eighth year anniversary of this bug. ;)

Comment 80

4 years ago
Hallelujah! :)

Comment 81

4 years ago
Holy sh*t! It's fixed! 

Good job, guys and girls!


Out of curiosity, can anyone elaborate on who had to take the last steps to fix this? The FF team, or gmail?
(Assignee)

Comment 82

4 years ago
(In reply to oda.krell from comment #81)
> Out of curiosity, can anyone elaborate on who had to take the last steps to
> fix this? The FF team, or gmail?

The Firefox side bug was bug 289384 which was fixed a while ago, and Gmail had to remove their old workaround for that bug which basically prevented these keystrokes to be handled by Firefox which is what happened now!
Whiteboard: [country-all][sitewait] → [country-all][sitewait] [good first verify]
You need to log in before you can comment on or make changes to this bug.