258684 - Change Linux shortcuts listed in Help to be correct

Status: RESOLVED FIXED

(Firefox Graveyard :: Help Documentation, defect)

Description

[Jeff Walden (gone starting June 8)]

Bug 257405 is playing havoc with keybindings on Linux.  We need to figure out
what to do and do it before 1.0PR, because this affects many different shortcuts
on Linux and has *major* implications in that many people are likely used to the
non-standard Firefox shortcuts.

Comment 1

[Pierre Chanial]

A introductionary sentence like "MF respects your GNOME edit keyboard
preferences" would be welcomed but I don't think that it's a priority for the
help manager to deal with emacs shortcuts. Those who use them have to do an
extra step to configure their keyboard in the gnome preference panel and well
know why they are doing that and what these shortcuts are.

Here are the modifs to your shortcut list:
The default gnome keybindings are similar to the windows ones except "Redo" 
which is shift-ctrl-Z only (ctrl-Y will be removed).
Ctrl-K is an emacs binding. It won't work with the default GNOME bindings and
should therefore be removed from the list.
Select All is now Ctrl-A, but it still have to be reflected in the UI. That will
be done very shortly (I have a patch)

Unrelated to this thread, but still relevent to you, on linux, ctrl-Y will call
the download manager...

And thanks for the great job!

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

Hi Jeff, now that we respect your system keyboard setting, I've made Linux also
use Ctrl+K to focus the search box so we're consistent now on all platforms.
(emacs fans can set their GNOME setting differently and use it for whatever it's
supposed to do, bryner assures me)...

The matrix for search looks like this:

Linux: Ctrl+K, J (for 0.8,9 compat)
Windows: Ctrl+K, E (for IE compat)
Mac: Cmd+K 

Comment 3

[Jeff Walden (gone starting June 8)]

Attachment: Patch

Comment 4

[Jeff Walden (gone starting June 8)]

Comment on attachment 158438 [details] [diff] [review]
Patch

Pierre, do you see anything *factually incorrect* in this patch?  (For
reference, anything with class="<platform>" will display on <platform>, while
anything with class="no<platform>" will display on all platforms except
<platform>.)

I'll run some of the wording by Steffen later, but for now I just want to know
if the shortcut changes are correct (because then we can finish this without
bugging you).

Comment 5

[Pierre Chanial]

Comment on attachment 158438 [details] [diff] [review]
Patch

shortcuts will be reflected in the UI in bug 258788.

Comment 6

[chris hofmann]

will get this right after PR and before the final localization freeze

Comment 7

[Jeff Walden (gone starting June 8)]

(In reply to comment #6)
> will get this right after PR and before the final localization freeze

Clarification may be needed here: the patch isn't ready yet.  I just wanted to
make sure that the patch is factually correct.  I still need to ask Steffen to
take a look at the wording, which I don't think is particularly good.  It's
certainly adequate if a quick fix were needed, but I'm not sure it's as good as
it should be.

Comment 8

[Jeff Walden (gone starting June 8)]

Comment on attachment 158438 [details] [diff] [review]
Patch

Steffen, how does the text added to the intro in this patch look to you?  It
doesn't seem quite good enough to me.  (Actually, the parenthesized sentence
should probably mention that the UI will show many of the shortcuts, especially
when the user's set custom GNOME settings.)

Comment 9

[Steffen Wilberg]

The explanation is a bit short indeed. I hope this helps:

The shortcuts in the table below apply, and are shown in the menus, regardless
of the text editing setting. But if you enable Emacs-style shortcuts
(http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#id2556828)
in the Gnome preferences dialog, these shortcuts take preference when the focus
is in a textbox, including the location and search bar. So when a textbox is
focussed, Ctrl+K doesn't focus the search bar, but deletes from the cursor to
the end of the line. Use Ctrl+J instead for Web Search.

>       <td>Redo</td>
>-      <td><kbd>Ctrl</kbd>+<kbd>Y</kbd><br/>
>+      <td><span class="noUnix"><kbd>Ctrl</kbd>+<kbd>Y</kbd><br/></span>
>         <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>Z</kbd></td>
Ctrl+Y should be "noUnix noMac", because it's inside a #ifndef XP_UNIX, which is
true on Mac as well. And this is intentional, see bug 258788 comment 0.

Comment 10

[Jean-Marc Desperrier]

In view of bug 259053, the change forces non-GTK users to use a GTK mechanism to
change the key binding.

Non-GTK users will not have the GNOME preferences dialog, so they'll need for
example to manually add inside ~/.gtkrc-2.0 the line 'gtk-key-theme-name =
"Emacs"' to get Emacs key bindings.

This should appear in the documentation.

Comment 11

[Jean-Marc Desperrier]

Sorry, there's a typo in the preceeding comment and the refered bug should have
been bug 259063.

Comment 12

[housetier]

I have here

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040913 Firefox/0.9.1+

I also have

# fix, so firefox uses ctrl+k to delete to end-of-line again
gtk-key-theme-name = "Emacs"

in my ~/.gtkrc-2.0

After restarting my x-session, ctrl+k still moves the cursor to that search
field on the right instead of deleting to end-of-line in the location field.

Comment 13

[Jeff Walden (gone starting June 8)]

Attachment: Patch w/comments addressed

I've tweaked the text some based on comment 9.	The revised text now is more
factually correct.  It's still not perfect, because I don't think we respect
*all* Emacs keybindings (like Ctrl+U), but it's factually correct for every
major keybinding we've always supported (K, A, etc.).

I also corrected the Redo shortcut to be correct on all platforms now, as
mentioned in comment 9.

Steffen, is this better enough?

Comment 14

[Steffen Wilberg]

Comment on attachment 159363 [details] [diff] [review]
Patch w/comments addressed

Thanks, Jeff. I don't think we need more than this.
r=me

Comment 15

[Jeff Walden (gone starting June 8)]

Fixed branch and trunk.

Note that because the Linux keyboard changes haven't made trunk from what I
remember, Help docs are inaccurate on trunk.  Firefox'll come back to trunk
eventually, so this is just in anticipation of then.  Trunk is in maintenance
mode right now until 1.0 is out, so trunk users should be expecting bugs and
mistakes.

Sometime relatively soon I'm going to fully update trunk Help with branch Help,
but I'm not sure when that'll be.  Until then, it'd be a good thing if we can
make all checkins to both branch and trunk (as I believe we have been doing
recently).  This'll save us headaches later.