Closed Bug 341886 Opened 18 years ago Closed 10 years ago

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

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

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

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox24 --- wontfix
firefox25 --- wontfix
firefox26 --- wontfix
firefox27 --- wontfix
firefox-esr17 --- wontfix
firefox-esr24 --- wontfix

People

(Reporter: jruderman, Assigned: ehsan.akhgari)

References

(
URL
)

Details

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

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)?
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.
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
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?
+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!
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.
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.
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...).
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
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.
This has become even more critical with the release of Google Wave. Surely we can look at changing the core firefox bindings?
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).
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?
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?
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.
Indeed, but that's bug 289384.
Assignee: nobody → ehsan
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Whiteboard: [post-2.0]
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.
I think this is something Gmail needs to fix. But they're probably waiting for us to fix bug 289384.
(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?
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.
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...
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!
Any updates on this bug?
Still no solutions? This bug is still not solved after more than 6 years.
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
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.
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.
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...
+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.
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.
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.
Shift-command-right should also move to the end of the line and select text up until the EOL as described in bug 906699.
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.
(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.
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.
(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!
(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!
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!
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!
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.
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.
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?
(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.
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.
> 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.
> 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?
(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!
> 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!
@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?
I would expect doing that to cause more problems than it would solve.  :/
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 !
Note that bug 289284 is very close to getting fixed.
(In reply to comment #65)
> Note that bug 289284 is very close to getting fixed.

Er, that was meant to be bug 289384.
Blocks: fxdesktopbacklog
Whiteboard: [post-2.0] → [post-2.0][triage]
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.
Whiteboard: [post-2.0][triage] → [triage]
Component: Editor → English US
Product: Core → Tech Evangelism
No longer blocks: fxdesktopbacklog
Whiteboard: [triage]
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>
You can also add the line:
    <only>FIREFOX</only>
right after the <identifier> line.
This will make the shortcut work only for Firefox
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?
(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.
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]
(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!
(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.
I heard back, they said they are hoping to get to this issue within the next month or two.
(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.
This is now fixed on the Gmail side.  You may need to refresh Gmail to get the fix.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Bummer, we were waiting for tomorrow's eighth year anniversary of this bug. ;)
Hallelujah! :)
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?
(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]
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.