214352 - emacs keyboard bindings override keyboard menu accelerators when keyboard focus is in text entry field

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Bitt Faulk]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701

If the keyboard input is focused in any text entry field, from those in forms to
the address bar, keyboard menu accelerators that are the same as emacs key
bindings fail, as the emacs key bindings override them.  Examples of ones that
fail that have viable menu accelerator uses are Ctrl-F, Ctrl-E, Ctrl-U, and,
especially, Ctrl-W.  Each of these makes sense in that context, or at least no
less than when the text entry field is not focused.

Making the text entry field no longer focused solves the problem, and using the
menu itself always works.

This is also true of the mail composition window, except that the accelerators
fail when the focus is in the addressing or subject lines, and the only
accelerator that seems to fail is Ctrl-W (the others don't exist in that context).

I don't know what the appropriate solution should be, but there are often times
I find that I have to use the mouse or hit tab (possibly numerous times) to
close a window or tab with Ctrl-W.  Other conflicts are possible as well.  The
most obvious would be to remap the menu accelerators back to Alt-<whatever> on
Unix platforms, or provide an option for that.  On at least the Windows
platform, emacs bindings don't work, so there's no conflict there.

I guess this must be a lower-level issue than just Browser-General, but I
couldn't find a more appropriate place; I apologize.

Reproducible: Always

Steps to Reproduce:
1. Open a window that has a text entry field
2. Focus the keyboard input in that field or in the address bar
3. Attempt to type Ctrl-W.

Actual Results:  
Either the word behind the keyboard cursor will be killed or nothing will happen
if no text existed in the appropriate place.

Expected Results:  
Closed the tab or window.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> The most obvious would be to remap the menu accelerators back to Alt-<whatever>
> on Unix platforms, or provide an option for that. 

See http://mozilla.org/unix/customizing.html#keys

Comment 2

[Bitt Faulk]

The fact that, by default, key bindings clash is invalid?  You've given a
workaround, not a solution, IMO.

Windows does not provide emacs bindings and doesn't have this problem.  I know
that I don't use them (at least in this context), except, possibly, for Ctrl-A
and Ctrl-E.  Perhaps an optional minimal emacs emulation would make more sense.
 Perhaps an optional vi-like binding?  Home and End already work.

It was also mentioned or implied somewhere (perhaps in comments on bug 22515)
that the default accelerator being Ctrl was because inexperienced *ix users were
more likely to expect Ctrl, which is fair, but wouldn't they also be
inexperienced with emacs as well, and wouldn't that make the appropriate thing
in that case for Mozilla to be more Mozilla-like and not more emacs-like?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Bitt, the current setup was arrived at after a lot of discussion and is what a
lot of other apps (eg Gnumeric) do when faced with a similar dilemma.  It's not
perfect, but it's somewhat consistent with other apps going forward, at least.

When we switch to GTK2, we should, imo, start following the GTK2 preference for
whether textfields use emacs bindings.

So the bug is invalid simply because all this has already been discussed and the
 current state of things is what was agreed on.

Comment 4

[Bitt Faulk]

Fair enough.  As long as it's realized that there is an issue that needs to be
thought about, even if it just means waiting on the underlying tech to fix it.

I sincerely appreciate the clarification.