keyboard shortcuts when keyboard set to non-english language

If I have modifiers other than ControlMask active in xevent->state then Ctrl-A,
Ctrl-E, etc. bindings don't work in the location field. Perhaps a "event->state
== GDK_CONTROL_MASK" should be "event->state & GDK_CONTROL_MASK"? Though someone
seems to have special-cased NumLock, the accelerators do work with NumLock for
me which is on mod2 or something. In any case, this is broken behavior, some
keymaps may even require non-control modifiers to be active in order to input
the "a" keysym. I have some code in the GTK unstable tree already related to
trying to fix this same problem for GTK itself; that code goes a step further
and tries to have "Ctrl + any key which has A printed on the cap" work, even if
the keysym isn't related to "A" at all, so that you can still use accelerators
despite switching between English/Hebrew keyboard groups. i.e. in Hebrew mode a
Ctrl + the English "A" key should still work. But fixing that may be overkill,
for now I'd just be happy if Ctrl-A worked with Caps lock or shift held down. ;-)

Not sure I understand this bug. Our key event system intentionally treats
ctrl-A as different from ctrl-shift-A and ctrl-alt-A. Is the problem here that
you want ctrl-shift-A and ctrl-alt-A to go to beginning of line just like ctrl-A
does? Or is it that our event system is doing the wrong thing with
ctrl-[othermod]-A (and if so, what should we be doing that we're not)?

In nsGtkEventHandler we do use & GDK_CONTROL_MASK, not ==, which it sounds like
we both agree is correct.

OK, you guys aren't going to want to go here for 1.0 probably. ;-) But I'll
explain the issues and maybe you want to deal with it eventually.

The original problem I had was a broken keymap, where caps lock was basically on
whenever I was holding control (both Lock and Control modifiers bound to one
key). So Ctrl-a didn't work. This is not really a big deal since I just unbroke
the keymap. But I would expect accelerators to be immune to caps lock, e.g.
imagine a text editor or the Mozilla composer, I'm typing with caps lock on, I
expect "Ctrl-s" to still save - Emacs does this for example, though you may want
to see what more user friendly apps do. However, Emacs treats Shift-Ctrl as
separate from plain Ctrl. It only ignores Lock.

As a bit of a tangent and a larger/harder issue, there are international
keyboards to consider. This is what we haven't fixed yet in GTK unstable version
and are planning to. The issue of ignoring shift/lock is just a special case of
the fact that users expect accelerators to work regardless of keyboard mode. For
example, a Hebrew/English keyboard would normally have a Mode_switch key,
bound to one of Mod1-Mod5, which toggles language. In Hebrew mode, you basically
want the key which generates "S" in English to still mean Save, since it will
drive users nuts if switching modes moves the accelerators around or removes
them. We have user complaints about this. So the way you do that is to query the
X keymap and find out which key generates S in English, roughly. The
keymap-query code is already in GTK unstable, and code to see which modifier is
Mode_switch, but we haven't yet sorted out all the issues; such as what if one
key generates several accelerators in different modes.

The user behavior I think is right is that the same key cap plus the same
non-persistent/non-mode modifiers always generates the same accelerator. So
basically to get the accelerator, you strip off the effects of whichever
modifier Mode_switch controls (one of Mod1-Mod5), strip off the effects of Lock,
then evaluate the result. For English you could just do something like ignore
Lock, or if Lock is set flip the case of the keysym, but ignoring the
Mode_switch modifier is important to, and there you need to query the English
keysym that would have been generated by that keycode absent the mode switch.
Also Num Lock is one of these modal modifiers, which you're already handling
somehow. (Num Lock brings up another pesky issue, which is that the mode
modifiers can apply to only a subregion of the keyboard.)

It isn't really totally clear what the right thing to do is in detail. If you
want I can point you at what we end up doing for GTK when we do it.

Relevant resources would be the Xkb spec from the X distribution, and useful
code from GTK unstable tree is in gdk/x11/gdkkeys-x11.c. I wrote that code and
it's available under MPL if you have any use for it.

so what is the bug? I am tempted to mark this INVALID, because as I understand
it, you had a broken keymap?

The bug sort of mutated. ;-)
This is what we've ended up implementing in GTK IIRC:

 - when we get a key event, first check whether the exact received keysym and
 mask is an accelerator

 - if not, then get a list of keysyms generated by the hardware keycode that
   was pressed in other groups/levels

 - see if any of those keysyms was an accelerator, then activate it

In other words, accelerators should work regardless of current keyboard
group/level. GTK devel sources contain the code for the second step if
you need it, you can have that code MPL, I wrote it. gdk/x11/gdkkeys-x11.c

This means that things work regardless of caps lock, but it also means that e.g.
Ctrl+s still works if the keyboard is in Cyrillic or Hebrew mode instead of
English mode.

You could argue with the exact solution, but the bug is that the same physical
keycap should be an accelerator despite group/level.

ok, this seems like a backend issue. aaron/akkana, do you want to take this? I
have no idea what to do with this and am just going to future it

Reassigning alecf keyboard bugs.

UNIX keyboard stuff -> Akkana

Akkana, send it on to whoever you think should have it.

The i18n issue is now addressed in GTK:
 http://cvs.gnome.org/lxr/source/gtk+/gtk/gtkkeyhash.c

Both underline shortcuts (mnemonics, Alt+f) and accelerators (Ctrl+s) are
placed in GtkKeyHash and then GtkKeyHash is used to resolve key press events
into an action.

Firefox 1.0 has been released and this problem still exists for Linux builds.

When you setup any international keyboard (at least through XKB, most common)
and switch to that other language, you are no longer able to use shortcuts in
Firefox.

This severely hampers usability since you cannot use the common
Copy/Cut/Paste/Print shortcuts.

In addition, GTK+ enables you to switch input method in any text field by
right-clicking in it and choosing that different input method. In Firefox 1.0
this option does not appear.

I have collected some more info on this and I put below.

Check out the following thread on this at the GTK+ mailing list.

http://mail.gnome.org/archives/gtk-i18n-list/2004-December/msg00016.html

(specifically check the followups).

The following Bugzilla bugs might be resolved through this issue:

1. "+ and - Keyboard accelerators inaccessible on international keyboards
(larger/smaller font size)"
https://bugzilla.mozilla.org/show_bug.cgi?id=88380

2. "some control key sequences don't generate the correct event (ctrl-enter
...)"
https://bugzilla.mozilla.org/show_bug.cgi?id=50255

3. "can't use gtk2 input modules ?"
https://bugzilla.mozilla.org/show_bug.cgi?id=164793

I think the following three are as well related to the core problem discussed here:
a. Unable to input Latin-1 chars using US keyboard with input locale set
to CJK
https://bugzilla.mozilla.org/show_bug.cgi?id=98376
b. Gtk2 XIM : Multi input context is not separated
https://bugzilla.mozilla.org/show_bug.cgi?id=218155
c. No way to switch the GTK input modules
https://bugzilla.mozilla.org/show_bug.cgi?id=214412
extract: "Yeah, SCIM and IIIIMF should 'solve' this problem without
anything changed on
the part of Mozilla. "

GTK+ 1.x (old stable version) had a bug and exhibited this exactly bug that
Firefox has. However, it has been resolved in GTK+ 2.x, therefore it looks good
to give control to GTK+ to handle input.
For a summary, see
http://mail.gnome.org/archives/gnome-i18n/2002-February/msg00051.html

Solving this core issue can clear up quite a few bugzilla entries.

Similar bug reported in OpenOffice.org.
X-posting the issue here:
http://qa.openoffice.org/issues/show_bug.cgi?id=39307

A similar discussion has occured at Bug 177508
https://bugzilla.mozilla.org/show_bug.cgi?id=177508

Shall we make Bug 177508 a DUP of this?

Yet another one at bug 246491. Another DUP? That one has 35 votes at the moment.

*** Bug 246491 has been marked as a duplicate of this bug. ***

So are we waiting for the GNOME people to do something? Cause if we are than a year of no progress means that maybe we should do something about it. And when I say 'we' I mean whoever knows his away around the keyboard input code of mozilla...

Adding relevant keywords. BTW, see recent regression bug 323212.

(In reply to comment #15)
> So are we waiting for the GNOME people to do something? Cause if we are than a
> year of no progress means that maybe we should do something about it. And when
> I say 'we' I mean whoever knows his away around the keyboard input code of
> mozilla...

It is indeed "we" who are expected to do something about this.

I cannot help in the programming part of this; I would be really happy to test experimental builds though.

GNOME has nothing to do with it. The keyboard configuration has nothing to do with it. It is really an application problem (well, xlibc could give some help - but currently IIRC it does not).
The application should grab the key regardless of the group. The principle, for, let's say "Ctrl-T" should be "if in _any_ configured group the symbol for this keycode is t, raise the signal". So even if my current layout is Russian, and I press Russian 'e' (which is on the same key as t in American layout), the shortcut is activated (sure if I press Ctrl at the same time).

Dublicates:
340944 Hotkeys In Linux with non-english keyboard layout
277893 Copy/Paste shortcuts not working with "russian" input locale

Please fix, I've tired to switch locale just to copy/paste text in my native language...

This is a very annoying bug that has been aroud for way too long. It's very cumbersome to switch locale everytime I need to copy-paste, to the point of making firefox on linux VERY unusuable with a non-latin keyboard layout. OpenOffice 2.0 learned to pick up the keyboard shortcuts just fine.

This bug is very annoying in non-Latin scripts. Is it possible to get it fixed for ff2.0?

bug 229284, bug 277893, bug 295614 and bug 340944 all look very similar.

This story longs from the mozilla 0.x and no one is able to fix it. All Mozilla applications are unusable under linux with non-english keyboard layout.

Please fix it in the Firefox 2, do not frustrate users ;-)

Not really "no one is able to fix it." Rather no one cares to fix it.

on FF2 rc1, still not working :(

would someone please explain to me what key i should press on my dvorak-right keyboard to trigger copy once this bug is "fixed"?

for reference <http://en.wikipedia.org/wiki/Image:KB_Dvorak_Right.svg>

suppose i'm using the hebrew localization of firefox.

also, what should happen if i switch to typing hebrew?

note that my keyboard is printed precisely as indicated in the picture.

Hm... Why new bug?
It's for current bug (Accelerators should not be affected by keyboard group/level), this patch makes gtk to think about it (and with it textEdits are not affected by group/level).
One change more and we would be able to discard from conversion to Latin-letters (it will fix the whole bug and depending bug).
About CVS I got it, I will do it in a right way.

Well, for one, this bug is an utter mess from all the advocacy comments -- it's almost completely useless for understanding the problem it's trying to fix, because you have to wade through so much to get to anything useful.

For another, people agreed enough that the original bug was fixed that they marked it fixed. If they thought various nits were part of that problem, they'd have required them to be fixed here before resolving the bug.

For a third, breaking issues into smaller pieces to deal with them is better for managing problem scope. You can't accurately estimate time to review or fix big problems. It's easier to know what must be done with small problems, rather than wondering whether a particular issue is on the table or not from only a few summaries of big bugs.

Last, and don't take this as criticism (more useful "political" advice in general), but when people more involved in a project (any project, not just Mozilla) than you asks you to do something in a slightly different but not indisputably worse way, and those people are willing to help with whatever you're doing, it's in your best interests to be accommodating. :-) Pedantic, nonsubstantive disagreement just isn't all that productive in practice -- you need other people's cooperation to see your issue fixed.

Oh, that :)
I haven't any disagreement, I asked a question only to understand why it should be done in another way, because it's really about this issue. I took part only in a small fpc module project from scratch, so it's a absolutely new thing for me.
At this moment I'm downloading the source from CVS and opening new bug.
Should I put here a link to the new issue?
Jeff, thanks you for your "political" advice :)
P.S. How should I call guys from the discussion? By name or surname nor both?

(In reply to comment #214)
> Should I put here a link to the new issue?

Certainly; mentioning followup bugs by number in the original bug is standard practice here (and I'd imagine across most bug systems, although I don't venture out of here often enough to guarantee it).

> P.S. How should I call guys from the discussion? By name or surname nor both?

Generally first names, or by bugmail address if no name is given. Deeply involved people may also get called by IRC nicknames, but it's certainly not necessary to do so, just faster/more concise. (It's also sometimes less ambiguous -- there are quite a few Mikes doing Mozilla stuff, for example. :-) )

Jeff, thanks for your answers :)

Bug 406407 was created. It fixes gtk bindings for textEdit (it caused a part of current problem).
I'm sure, that there is a way to make Bug 69230 fixed without conversion to Latin (and issuing Bug 399939).

(In reply to comment #216)
> Jeff, thanks for your answers :)
>
> Bug 406407 was created. It fixes gtk bindings for textEdit (it caused a part of
> current problem).

Would it make sense to block the current bug (69230) by the new bug?

What does it mean, to block the bug (sorry, that I ask here)?

(In reply to comment #200)
> As per popular request here is a rediffed version of the patch for firefox 2.0.
> Diffed against firefox source code 2.0.0.10.

When do this patch include to gecko 1.8.1.x? I am waiting it for seamonkey 1.1.x

*** Bug 407355 has been marked as a duplicate of this bug. ***

*** Bug 407356 has been marked as a duplicate of this bug. ***

(In reply to comment #218)
> What does it mean, to block the bug (sorry, that I ask here)?

The term "block" is heavily overloaded. "X blocks Y" implies "Y depends on X", and it can mean that X must be fixed before Y can be fixed, that X is a regression from fixing Y, or that X must be fixed for Y to be considered fully fixed (which doesn't necessarily imply that Y can't be marked fixed before X is marked fixed).

It's all a bit confusing, really. We sort of want more knobs to turn to record these things more precisely, but Bugzilla UI is already full enough that nobody's really been interested in spending effort to add yet more of it (and get it past the inevitable UI bikeshedding discussions).

Jeff, thanks a lot! Great explanation, I got it.
In this context I hope I will kill one of Xs this evening :)

Some of the shortcuts problems are caused by clipboard handling, see Bug 407604.

*** Bug 417060 has been marked as a duplicate of this bug. ***

The bug is now marked as RESOLVED/FIXED. Will it be included in upcoming Firefox updates? Or is it scheduled for FF3?

It will affect Firefox 3.

The fix has been included in Firefox 3. I doubt it will be backported to Firefox 2.

I just tested with Firefox 3.0beta3 and it works really great.

It Works! tested with FF v3.0b3 (us qwerty + greek qwerty layouts)

MANY THANKS to everyone involved!

Comment on attachment 290399
look for latin key if modifier is down [rediffed for firefox 2.0]

It's very annoying. Everybody is tired from it

(In reply to comment #230)
See comment 201.

Created attachment 307428
Rediffered for ff2 with fix (comment 201)

Sorry, didn't notice it.
Karl, it the thing we are talking about in Bug 399939. With this change we should be free to apply this patch to ff2.

This bug manifests again in recent SM trunk builds (last week or so) - on Windows (and using Hebrew keybouard layout). Has there been a related check-in recently?

(In reply to comment #233)
> This bug manifests again in recent SM trunk builds (last week or so) - on
> Windows (and using Hebrew keybouard layout). Has there been a related check-in
> recently?
>
This is Bug 429180

(In reply to comment #233)
> Windows (and using Hebrew keybouard layout).

Bug 429970. No check-in yet.

*** Bug 425350 has been marked as a duplicate of this bug. ***

I'm seeing this on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060909 Iceweasel/3.0 (Debian-3.0~rc2-1).

... and also in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 (still on Debian sid). Both on a clean profile, with Hebrew layout. So apparently the problems are not unique to Win32 and are not yet solved. I think it did work at some point on Hardy, but I just checked there and it's FF3RC3 and I see the same problem.

Which shortcuts exactly is there a problem with? I'm not seeing anything not working on Hardy with Hebrew layout.

(In reply to comment #238)
There must be a Latin keyboard layout enabled (but not necessarily selected) if you wish Latin accelerators to function based on their corresponding keys in a Latin layout. Check the enabled layouts with "setxkbmap -print". Despite the setxkbmap man page you can use that command to enable two layouts with something like "setxkbmap -layout il,us".

If this still doesn't work with a Latin layout enabled or if your normal layout-switching tool doesn't provide the necessary functionality then please file a separate bug with some details and CC me. (This bug report is already too long.)

I'm running firefox on hardy with Hebrew and English keyboard layouts. I found that the Ctrl-W shortcut for closing the current tab only works on the English layout, while the cut-copy-paste shortcuts work on both layouts.

Haggai

Ctrl plus C,V,X,P,W,A,Z,Y,F,H,L work just fine here:

1) Mozilla/5.0 (X11; U; Linux i686; el-GR; rv:1.9) Gecko/2008060309 Firefox/3.0
2) Keyboard Layouts
   a) US Qwerty
   b) EL (Greek) Qwerty
3) Ubuntu Hardy (8.04)

@Haggai:
Like Karl said, you need to enable the Latin layout in Hebrew as well. If you use KDE 3.x it is done here (translated from Hebrew):
Kcontrol -> Localization and Disability -> Keyboard layouts -> Now select the Israeli layout by clicking on the relevant line under Active Layouts (פריסות פעילות) -> Check the "Include Latin layout ( )" button.

@Haggai:
Like Karl said, you need to enable the Latin layout in Hebrew as well. If you use KDE 3.x it is done here (translated from Hebrew):
Kcontrol -> Localization and Disability -> Keyboard layouts -> Now select the Israeli layout by clicking on the relevant line under Active Layouts (פריסות פעילות) -> Check the "Include Latin layout (כולל פריסה לטינית)" button.

I don't use KDE - I use gnome. I think I already have a latin keyboard layout as well as the Hebrew layout. Here's the output of setxkbmap:
> $setxkbmap -print
> xkb_keymap {
> xkb_keycodes { include "xfree86+aliases(qwerty)" };
> xkb_types { include "complete" };
> xkb_compat { include "complete+ledcaps(group_lock)+ledcaps(group_lock)" };
> xkb_symbols { include "pc+us+inet(logiclx300)+il(lyx):2+group(caps_toggle)" };
> xkb_geometry { include "pc(pc104)" };
> };

Is that ok?

Haggai

@Haggai:
I really don't know. Try asking on your distro's mailing list or on linux-il.

I can confirm that Ctrl-W and Ctrl-Q do not work with the Hebrew layout active, although other Ctrl- shortcuts do work, but as Karl says this should be reported as a new bug.

Wow, you are right, I can reconfirm that CTRL-Q and CTRL-W do not work, though CTRL-A, Z, X, C, V, P, F, H, B, and L do.

Yes, this bug is not fully fixed. I think some Firefox 3.0 beta versions fixed this bug completely, but since then there was this regression.

This bug should be reopened.

@Elez:
It appears that the new regression is not related to the original fix. Please comment on Bug #452393 with your locale and the keyboard shortcuts that do not work in your keyboard layout.

Everyone else who uses non-US keyboard layouts is encouraged to check the following accelerator combinations and to report in Bug #452393 which accelerators work and which do not:
CTRL-Q, W, A, Z, X, C, V, P, F, H, B, L

https://bugzilla.mozilla.org/show_bug.cgi?id=452393

*** Bug 374585 has been marked as a duplicate of this bug. ***