Closed Bug 69230 Opened 24 years ago Closed 17 years ago

Accelerators should not be affected by keyboard group/level

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: hp, Assigned: oleg.krylov)

References

(Blocks 2 open bugs)

Details

(Keywords: intl, platform-parity)

Attachments

(4 files, 6 obsolete files)

ignore keyboard group/level
3.36 KB, patch
Details | Diff | Splinter Review
review roc@ocallahan.org
2.14 KB, patch
Details | Diff | Splinter Review
look for latin key if modifier is down [try3]
6.29 KB, patch
roc
: review+
roc
: superreview+
mconnor
: approval1.9+
Details | Diff | Splinter Review
Rediffered for ff2 with fix (comment 201)
6.32 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Summary: Location textbox Emacs-style bindings don't work with other modifier bits set → Accelerators should not be affected by keyboard 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
Priority: -- → P3
Target Milestone: --- → Future
Reassigning alecf keyboard bugs.

UNIX keyboard stuff -> Akkana

Akkana, send it on to whoever you think should have it.
Assignee: alecf → akkana
Depends on: atfmeta
No longer depends on: atfmeta
Blocks: atfmeta
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
Blocks: Persian
Blocks: 177508
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.
Blocks: 246491
Assignee: akkzilla → aaronleventhal
QA Contact: bugzilla → keyboard.navigation
*** Bug 246491 has been marked as a duplicate of this bug. ***
No longer blocks: 246491
Blocks: 240501
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.
Keywords: mail4, pp
(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).
Keywords: helpwanted
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.
(In reply to comment #26)
> would someone please explain to me what key i should press on my dvorak-right
> keyboard to trigger copy once this bug is "fixed"?

quoting myself on IRC: either shortcuts are bound to physical keyboard buttons, or to logical key combinations, or both possibilities can be supported, pref-controlled. But w.r.t. this bug the most important thing seems to be making behavior on Linux conform to that on other systems.
Logical keys are not an option, since you cannot type e.g. Ctrl-Z in a non-Latin mode, like any Cyrillic, Hebrew or whatnot.  I can see only one sane solution: bind to physical keys.

However this is all meaningless as long as Firefox developers are not fixing this bug.  It is open for what, more than five years, huh?
paul: first instead of complaining that the bug isn't fixed. *answer* my question.  bind to *what* physical key?

we can't fix bugs without having a specification that addresses such questions.

do note that you could use a localization that bound ctrl-{somehebrewcharacter} to undo. -- i'm not sure that's necessarily the best thing to do, but it's certainly what people expected to have happen when they designed this system.
Then instead of non-working undo in Russian keyboard mode, i'll get non-working undo in English mode.  Not much better, really.  I actively use both keyboard layouts and I wish everything worked regardless of the active layout (except, of course, the keys I typed.)

I propose to use _English_ shortcuts and bind them to keys that type corresponding English characters when the current layout is English.

In fact, there are many examples, both GNOME and KDE work as expected and I'm sure Windows does too.  Instead of inventing something new, I suggest not infuriating users and just use the standard approach.

timeless: an interesting question. Maybe we should take a look at how non-mozilla programs solve this. So what physical key triggers "copy" on your keyboard in some gtk or kde application? Is it always the one labeled as "C"?
(In reply to comment #30)
> In fact, there are many examples, both GNOME and KDE work as expected and I'm
> sure Windows does too.  Instead of inventing something new, I suggest not
> infuriating users and just use the standard approach.

Agreed. However, 

> bind them to keys that type corresponding English characters when the current layout is English.

can't be what is done now in Windows, because:
1. There are numerous layouts for English (QWERTY,Dvorak, others?)
2. Sometimes X is configured not to have any group at all with some level corresponding to English

Also, there are other apps, in KDE and probably also in Gnome, that are broken in much the same way.
 
timeless: see comment #4 for what gtk does. Can you take it as specification?
OK, there must be some sort "raw key value" in the key event structure.  I.e. something not translated with current layout etc.  This is probably the only anchor valid in all layouts, so I guess shortcuts have to be bound to it.  I cannot really predict how it will work with US Dvorak layout, since I never used it.  How do other (GNOME, KDE, Windows) applications work?

windows dvorak layouts map keys based on what chars appear when you type them, not what chars would appear if the layout was qwerty.

the same applies for latvian which has things in various interesting places.

if i take comment 4 as a spec, then i'm pretty sure that the summary here is wrong and needs a rewrite. i'm open to someone proposing a new summary. but please don't actually change it, just make a proposal.

but it isn't quite that consistent, i think i found some layouts which just used the standard positions (even though they had the keys elsewhere). i can't explain all the rhymes/reasons. i think some even temporarily let me use the letters and then after i used the keys forced me to use the keys.

i'm fairly certain we'll never be able to please everyone.

smontagu notes that mpt noted that on osx you can choose which behavior you wanted.
(In reply to comment #35)
> i'm fairly certain we'll never be able to please everyone.

Implement both possibilities, with a pref to choose between them - won't that please everybody?

> smontagu notes that mpt noted that on osx you can choose which behavior you
> wanted.

Exactly. Anyway, right now the only behavior on gtk is the one which displeases the majority. So either both possibilities are supported, or as a first step we make our gtk behavior similar to the Windows one; that's what I think should happen anyway.
(In reply to comment #35)
> i'm fairly certain we'll never be able to please everyone.

Implement both possibilities, with a pref to choose between them - won't that please everybody?

> smontagu notes that mpt noted that on osx you can choose which behavior you
> wanted.

Exactly. Anyway, right now the only behavior on gtk is the one which displeases the majority. So either both possibilities are supported, or as a first step we make our gtk behavior similar to the Windows one; that's what I think should happen anyway.
I've followed this thread and it is obvious that it's difficult for developers that only speak english to understand this bug. That's normal. So I'll try to  uncover the problem we are facing. You'll just have to try the following 7 steps in your PC:

1) add a greek layout for your keyboard (greek is just a layout which I know for certain that trigers the bugy behaviour)
2) open firefox and go to a page with a text field (for example bugzilla)
3) write a few english words 
4) hit ctrl-A. It will select the whole text area. 
5) hit an arrow to deselect the text 
6) switch your keyboard layout to greek 
7) hit ctrl-A just like you did before. It will do nothing. We wish it would perform exactly as before (this and all other super-usefull shortcuts like ctrl-C,V,X,Z)

If you think about it, the reason almost[*] everybody wants it that way becomes obvious:  Just imagine your self programmin in C. You are at the point that you're writting those boring sprintf's that present a lot of localised messages to the user. It is darn hard to try hiting different key-combinations for cut / copy / paste / undo when you are typing the english C commands and variables and different combinations when you are typing the localized messages. And this is the same for alot of computer tasks because having to type both english and non-english text as well as mixed text is quite common. 

To sumurize:
it *MUST* be the same finger motion for the same effect. And what finger motion should that be for Greek or for Russian or for "name-a-language"... but ofcourse just the one that you are using when you are typing english text. Why so? Because many computer users in those countries are typing quite alot of english every day. For certain all "power" users do type a lot of english every day (and if you can excuse my humor: "because they have to at least type the bug reports :-)")

__________
* BTW I don't know anybody who doesn't like it this way
just to add to Nick's comment, this behaviour should be regardless of whether you have QWERTY or Dvorak layout in english. when the keyboard is in non-english mode, the keypress should be as if we were in english mode, on whatever key layout is used.
(In reply to comment #39)
> this behaviour should be regardless of whether
> you have QWERTY or Dvorak layout in english. when the keyboard is in
> non-english mode, the keypress should be as if we were in english mode, on
> whatever key layout is used.

Quite so: this is one of the reasons why this bug is hard to fix. Suppose I have English QWERTY, English Dvorak, and Hebrew keyboard layouts installed, the Hebrew layout is active, and I press Ctrl+כ (i.e. the key which is "F" in QWERTY keyboard and "A" in Dvorak.

Should this activate Select All or Find?

(In reply to comment #34)
> OK, there must be some sort "raw key value" in the key event structure.  I.e.
> something not translated with current layout etc.

Apparently not :( Using the same example, QWERTY Ctrl-F, on https://bugzilla.mozilla.org/attachment.cgi?id=55849 I get the following

USA QWERTY:
1) keydown charCode=0 keyCode=70 character=|
2) keypress charCode=102 keyCode=0 character=|f| modifiers=Ctrl
3) keyup charCode=0 keyCode=70 character=|

Israel si1452:
1) keydown charCode=0 keyCode=0 character=|
2) keypress charCode=1499 keyCode=0 character=|כ| modifiers=Ctrl
3) keyup charCode=0 keyCode=0 character=|

USA right-handed Dvorak:
1) keydown charCode=0 keyCode=65 character=|
2) keypress charCode=97 keyCode=0 character=|a| modifiers=Ctrl
3) keyup charCode=0 keyCode=65 character=|
As I noted in comment #2, this bug was filed when we were implementing the right behavior in gtk, and the gtk code is available under MPL since we wrote it at Red Hat and are willing to donate it. Since this is a Linux specific bug, copying the gtk behavior is almost certainly right. There's some scary Xkb magic involved iirc, though obviously I don't remember code I wrote 5 years ago in any detail.

Is this the code that will need to be modified?
  http://lxr.mozilla.org/mozilla1.8/source/widget/src/gtk2/nsCommonWidget.cpp#149
In particular, nsCommonWidget::InitKeyEvent() calls GdkKeyCodeToDOMKeyCode() with aGdkEvent->keyval.

hp@redhat.com -- can you add a URL of the source code you are offering?  Can we try to piece together enough to see if *any* of this *might* work?
http://cvs.gnome.org/viewcvs/gtk+/gdk/x11/gdkkeys-x11.c
is one of the files. For the Linux version of Firefox you can probably just call those functions come to think of it, instead of cut-and-pasting all the Xkb cruft-o-rama. Keep in mind that the keymap can change on the fly so you have to either not cache anything or watch the change notification.

Then on top of the low-level keymap/xkb goo, there is an internal API that resolves which accelerator a given key press should activate:
http://cvs.gnome.org/viewcvs/gtk+/gtk/gtkkeyhash.h
http://cvs.gnome.org/viewcvs/gtk+/gtk/gtkkeyhash.c

If you look at GtkKeyHashEntry, it contains a GdkKeymapKey which is from the gdkkeys-x11.c API. This is then used to examine other keyvals on the same physical keycode.

The algorithm you probably want to see is in _gtk_key_hash_lookup

if you have a GdkKeyCodeToDOMKeyCode() you're probably going to get confused btw, since it sounds like it uses what gdk calls keyvals (symbolic key names), but gdk also has keycodes (hardware scancodes)

(In reply to comment #40)
> (In reply to comment #39)
> > this behaviour should be regardless of whether
> > you have QWERTY or Dvorak layout in english. when the keyboard is in
> > non-english mode, the keypress should be as if we were in english mode, on
> > whatever key layout is used.
> 
> Quite so: this is one of the reasons why this bug is hard to fix. Suppose I
> have English QWERTY, English Dvorak, and Hebrew keyboard layouts installed, the
> Hebrew layout is active, and I press Ctrl+כ (i.e. the key which is "F" in
> QWERTY keyboard and "A" in Dvorak.
> 
> Should this activate Select All or Find?
> 
It should activate whatever function is activated when you are on english layout. That's all there is to it: If I press ctlr and the 4th key on the 1st row I should get the same behaviour no matter what the keyboard layout.
I'd say it is quite meaningless to have both US Qwerty and US Dvorak on the same machine.  Sure you can have both, but then you can hardly blame an app if it behaves weirdly in one of them.

Ideally, it should behave if your English layout is Dvorak as if in the Dvorak for shortcut things (and not if is in QWERTY.)  However, I'm not sure that this is easy to implement.

I agree with Nick Demou that either way shortcuts *must* be the same physical keystrokes in all layouts.  If it is possible to solve QWERTY/Dvorak problem, it should be done.  But AFAIK QWERTY is much more widespread, so it should be a top priority.

IMHO it should not use the keycode, but the secondary layout that is defined like this "setxkbmap -model pc105 -layout us,ru" (for Russian ru with secondary US-English us).
This is important because there can bei different latin layouts as secondary: qwertz, qwerty, azerty, ...
In terms ok XKB, I would put it this way: 
If shortcut is Ctrl-a - walk across all keys defined in the current configuration. If for some key the keysym is "a" in ANY group - listen to Ctrl-<keycode>, ignoring the group.
It's a pity that the most annoying bug of all times is still not fixed in ff2.
I hope that this discussion will lead to a fix in the next minor release, asap, and not in ff3 only.

about the dvorak/qwerty dilema. I think the behaviour should be that if the Ctrl-<keycode> matches to more than one group, from the list of groups that are installed, give priority to the group that is now active. 
Most of the time when using groups for different languages, the keycodes will match only to one group.
^^^
In a case when Ctrl-<keycode> matches to more than one group, from the list of groups that are installed, and none of them is the active at the moment, well..., in this case just use the first one. I think that this scenario is so rare, that it won't bother anyone.
(In reply to comment #49)
> I think that this scenario is so rare, that it won't bother anyone.

Exactly!

I'm aware that having to address the fringe cases is important (see how MS fail where it shoes that they didn't consider all possible situations), but holding a practical solution for 99.9% of the cases just for this 0.01% which can probably be overcome with some extra user preferences settings is not a convincing reason IMHO.

(In reply to comment #50, #49)

Indeed, this is a theoretical discussion which can be postponed. For now there should be parity between the Linux behavior and that on Windows, and this will satisfy the 99%. As for the question of what to do when someone has both Dvorak and Qwerty, let's deal with that afterwards.
right.  there's a pretty easy solution to the corner case, anyway: walk the keymap, and if the accelerator you're using has a different definition in the current and primary groups, then prefer the current one.  (or, if they're on unique keys, such as if you have us and german, and you have an accelerator on ctrl-z, but not on ctrl-y, then launch them both on us z in the bottom row, and german z in the top row.)  this will only trigger for the qwerty/dvorak case, since the russian layout has only cyrillic keysyms.  it's a pathological corner case, anyway.

-daniel, xkb codebase maintainer (sergey udaltsov is the layouts maintainer)
@Paul: I do have US English and US Dvorak on the same machine (and Hebrew as well). I personally prefer to type in Dvorak, but the keyboard is labeled in English. My wife, who must look at the keyboard while she types, needs a layout that matches the keyboard, hence US English. Also, sometimes others do use this machine, so qwerty in nessacery.

I'd personally like all the keyboard shortcuts to be bound to physical keys, as if the keyboard were always qwerty. I'd even go so far as to configure this at the X level, if I only knew how. In fact, that's how I got here- I was searching for ways to configure Ctrl-K (when in Dvorak) and Ctrl-ה (when in Hebrew) to always return Ctrl-V, the qwerty letter on the same key.

Yes, I agree on this.  I think binding to physical keys is the only absolutely unambiguous alternative.  Other solutions are possible, but are more difficult to implement and there will be cases when they won't work or will work not as one would have expected.

Some notes on severity of this bug. It is not a Firefox blocker dug, but in certain cases it can be a major bug for an entire Linux distribution. When I attempted to teach in computer class with Linuxes some students were really frustrated by this bug.

I "localized" https://update.mozilla.org/firefox/3529/ to support Hebrew keyboards as well, but it was too late. This workaround is good, but it is not a real patch.
Most of the problems with this bug are experienced by Russian and Hebrew keyboard users, so I guess that such workaround would provide better support with zero functional regression and can be added to the Trunk at least as temporary measure.
(In reply to comment #51)
> (In reply to comment #50, #49)
> 
> Indeed, this is a theoretical discussion which can be postponed. For now there
> should be parity between the Linux behavior and that on Windows, and this will
> satisfy the 99%. As for the question of what to do when someone has both Dvorak
> and Qwerty, let's deal with that afterwards.
> 

Well said. Also Firefox on Linux should behave similarly with the rest of the desktop applications. 
(In reply to comment #56)
> 
> Well said. Also Firefox on Linux should behave similarly with the rest of the
> desktop applications. 

Other Toolkits face similar problems, e.g.:
KDE Bug 71147: Alt-shortcuts dont work with secondary layout
http://bugs.kde.org/show_bug.cgi?id=71147
In Gnome, all other GTK apps (Opera, OpenOffice) have working keyboard shortcuts when the user is in a non-latin alphabet such as Hebrew or Russian. Only Firefox does not. In KDE, no apps have working keyboard shortcuts when the user is in a non-latin alphabet. So  there are two problems: one in Firefox, and one in KDE. The KDE problem is the responsibility of the KDE developers, but the Fx problem is the responsibility of the Mozilla developers, no? 
KDE Ctrl-shortcuts work for Russian. Please see my reply at http://bugs.kde.org/show_bug.cgi?id=71147.
Very annoying and long lasting bug. FIX IT PLEASE!!!
BTW, Epiphany isn't affected by this bug.
Isn´t the QWERTY vs Dvorak discussion a little irrelevant? Even if "a" is in different locations on your keyboard, you still have an "a" key to press. Unlike non-latin languages (the greek layout has an "alpha" but not an a).
So, a fix should only provide new shortcuts for non-latin keyboards. By the way, if a ctrl+"alpha" shortcut was available to all users, people that don't have greek installed would not even know it's there, not having an alpha key. And the same goes for cyrillic or hebrew keyboards.
Yes, with Dvorak I still have an A to press. But you might want to research muscle memory: that is the reason that keyboard shortcuts should be bound to keys and not to letters. Whether it be US English, Dvorak, Russian, or Hebrew layout, the same key combination should have the same effect.
(In reply to comment #55)
> Some notes on severity of this bug. It is not a Firefox blocker dug, but in
> certain cases it can be a major bug for an entire Linux distribution. When I
> attempted to teach in computer class with Linuxes some students were really
> frustrated by this bug.
> 
> I "localized" https://update.mozilla.org/firefox/3529/ to support Hebrew
> keyboards as well, but it was too late. This workaround is good, but it is not
> a real patch.
> Most of the problems with this bug are experienced by Russian and Hebrew
> keyboard users, so I guess that such workaround would provide better support
> with zero functional regression and can be added to the Trunk at least as
> temporary measure.
> 

There is an additional extension that covers Greek, 
https://addons.mozilla.org/en-US/firefox/addon/4764 
by Athanasios Lefteris. As I understand it, it's derived from the Russian extension.

I do not know the effort required to get the standard GTK+ behaviour (as found for example in Epiphany) in Firefox on GTK+/Linux. I believe people here would be more than willing to test patches.
This bug is already 6(six!) years old. There are extension resolving this issue (e.g. https://addons.mozilla.org/en-US/firefox/addon/3529 for Russian qwerty, Ukrainian qwerty, Russian Dvorak and Greek layouts)

But no word on whether this issue is ever going to be addressed in the browser itself...
This should not be the work of extensions. Extensions are for enabling new functionality to the browser. Extensions are not for bugfixes. I've already begun replacing Firefox with Konqueror as konqueror seems to be in active development. Issues such as the accelerator keys, memory leaks, and others make Firefox seem to be abandonware. Simply bumping the major version number up when adding a spellchecker and session management feature (both already available as extensions) proves that development of the core of the browser has been abandoned. I've even had to remove the Get Firefox links from my personal site as I can no longer recommend Firefox to new users.
https://addons.mozilla.org/en-US/firefox/addon/3529 works great for Russian keyboard ))
May be it is finally (after 6 years) time to include the fix to mainstream code???
(In reply to comment #67)
> https://addons.mozilla.org/en-US/firefox/addon/3529 works great for Russian
> keyboard ))
> May be it is finally (after 6 years) time to include the fix to mainstream
> code???
> 

It's not a fix. It's workaround.
(In reply to comment #68)
> (In reply to comment #67)
> > https://addons.mozilla.org/en-US/firefox/addon/3529 works great for Russian
> > keyboard ))
> > May be it is finally (after 6 years) time to include the fix to mainstream
> > code???
> > 
> 
> It's not a fix. It's workaround.
> 

Call it whatever you want - at the level of the most recent discussions ("we can't fix it because it won't cater for very weird keymapping combinations that someone's cat on the space station must use") it just goes to show that it is practical to find a solution that just works (TM).

@timeless  (comment#29):
You can use xev to determine which keys, this will work in all layouts. For instance, C is keycode 054.

@Paul Pogonyshev (comment#34):
Xev gives the "raw key value" of which you speak. If you bind, for instance, Copy to keycode 054, then it will copy with or without CapsLock, in Hebrew, Russian, English, Dvorak, Greek, and every other layout. That's what we've been asking for. Note that I myself use English, Hebrew, and Dvorak. I _need_ the bindings to be on physical keys (as per the English layout).

@Tsahi Asher  (comment#39):
As a Dvorak user, I second your opinion that they keybindings should be as they are in English.

It seems that all the hard work had been done: the community has agreed on desired behaviour and the technical method is worked out. Extensions have even been written that handle this. So when can we expect it to be moved into trunk? I really dislike Konqueror, but I'm forced to use it because I'm a heavy keyboard user and the shortcuts don't work in Firefox.
The attached patch makes Firefox ignore the current keyboard group and level in accelerators by always looking up keyval by group 0 and level 0 when any control key is pressed.

I tested it a little and it does make ctrl- and alt- sequences work even in Hebrew mode. It even fixes even a different bug, that ctrl-shift-i don't invoke the DOM inspector when capslock is on.

Note that the patch removes from the code a few special cases that handle other bugs, because I wasn't sure how it might interact with them. I haven't looked deeply into these bugs, but from the comments it looks like the special cases may not be needed anymore.
Thanks amnonaar.  I just have some questions.

Why group 0?  Does it force user to have a Latin layout in the first group?  Actually I don't think it works if you *only* have the Hebrew layout.

Have you seen the GTK+ behavior?  It almost checks all groups to find a match.  It's needed as it's so better to translate accelerators and shortcuts, and have the localized one one the screen, and find it on the appropriate group.
Yes, it does force the user to have a Latin layout in the first group. Actually it should look for the first Latin (English?) layout, but I don't know how to do that. 

If you only have a non-Latin layout you can't enter URLs or login to webmail accounts so you probably don't worry about keyboard shortcuts.

I did see the GTK+ behavior but I don't know enough about Mozilla to get the information the GTK algorithm seems to need. It's a quick hack, but it's better than nothing.

Any progress??
I guess not. Most bugs regarding this issue end up redirecting here... To no avail.

This bug is 6 years and 6 months old, BTW. I guess it is the oldest bug marked as NEW in bugzilla database.

I suppose we should mark it as blocking some soon-to-be-released milestone of FF...

Apparently we have to work ourselves to solve this, as Amnonaar is doing above.

For now, there are nasty workarounds that are implemented using extensions; such workarounds exist for Russian (link above) and also Greek (in Mozilla extensions sandbox).
Someone should mark bug 229284 and bug 340944 as dups of this one.
I really wonder if *anybody* from mozilla is watching over this bug:

 * First it's been six years
 * Then nobody cares to mark obvius dupes as such\
 * Finally this bug is for many years assigned to the same person, an Aaron Leventhal who has only made a comment 6 years ago. If you look at the bug activity page you'll see that he has labeled the bug with a "HelpWanted" some 18 months ago and he also has *removed* his email from the cc list of the bug 5 months ago. Does this really mean he doesn't get any email about it? Don't know for sure but it looks very much like he doesn't!  Then I read Aaron Leventhal's proud words about firefox's accessibility: "The Firefox accessibility effort has now truly achieved ignition, not only with base accessibility support in Firefox, but also by leading the future of accessibility for dynamic web applications."...and I can't fight some sarcastic thoughts like "after 6 years of dealing with accessibility issues affecting their disabled users how about dealing with major accessibility issues affecting ALL of their non English speaking users". Don't get me wrong, I know that this is voluntary work, but I aslo know that: 1) if you can't/don't want to do a job then don't accept it, and 2) if you've left important parts of the job uncompleted don't tell the the world how proud you are about your accessibility masterpiece.

So I still wonder if *anybody* from mozilla is watching over this bug and my guess is: "no they don't"
It seems that nobody from Mozilla actually looks at this bug. Why don't you ask
your questions on IRC? Even if somebody writes a patch, he or she should
request review and approval from Mozilla guys.

@Nick Demou (comment #80) (and to all Greek users)

In the mean time, you can try the next sandboxed add-on, which fixes the bug for Greek keyboard layouts:
https://addons.mozilla.org/en-US/firefox/addon/4764

Egor Pelevin   2007-08-22 03:09:46 PDT
>  Why don't you ask your questions on IRC?

(supposing that the above comment was ment for me:) well I've never used IRC in my life but I'm sure it want be hard. What address/url/channel or whatever-is-the-name should I go to?
(In reply to comment #83)
> Egor Pelevin   2007-08-22 03:09:46 PDT
> >  Why don't you ask your questions on IRC?
> 
> (supposing that the above comment was ment for me:) well I've never used IRC in
> my life but I'm sure it want be hard. What address/url/channel or
> whatever-is-the-name should I go to?
> 
It was for everyone :)

I'm not sure, but #developers on irc.mozilla.org seems appropriate. At least you can find Mozilla devs on it.

> in the mean time, you can try the next sandboxed add-on

Even though the extension exists, there's a valid point in comment 66, https://bugzilla.mozilla.org/show_bug.cgi?id=69230#c66

"
This should not be the work of extensions. Extensions are for enabling new
functionality to the browser. Extensions are not for bugfixes.
"

As there are great many other languages that need to be fixed. 

Funny thing is that there's a patch from comment 55, however I don;t think it made it anywhere
I've logged on to #developers and here's the latest info:

At least one developer will look into the problem. At least one more will sort
of "assist" him and I will try to do my best to test patches when/if they
appear:

Here's the log (I've changed nicknames, not sure developers are ok with me
posting the log here)

-----------

dmitriid> i wondered if a developer could look at a 6-year old bug in bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=69230

dev1> do you think the bug is in mozilla or gtk?

dmitriid> i think it's mozilla, as do other commenters on the bug
dmitriid> see also comment 10, for instance
dmitriid> and comment 18

dev1> does the patch work for you?
dev1> the patch in comment #71?
dev1> that one suggests it is a complete fix

dev2> although a little hacky maybe
dev2> but i don't know enough to say that its wrong

dev1> comments 72 and 73 suggest room for improvement too

dev2> I'm not sure when I'll get to it, but I may ask you to try some things
for us

dev3> Simply put you can't press Ctrl-F if there in no "F" in your layout. So
it's a general bug for non-Latin layouts. I can help too

dev2> are either of you comfortable with patches and building from source

dmitriid> well, if it doesn't raise any errors :)

dev3> there is an F on the keyboard, but in Russian it's mapped to cyrrilic А
dev3> well, I'm not a developer...
dev3> but I can try

dev2> there are serious issues that we still need to fix for ff3, but I can see
this would be useful

-----------

So there you go :)
dev3 = ego = me :)
Dmitrii are you still in contact with those helpful developers? If you are do you think it would save them time if we prepared a summary of this long thread (and some other's of duplicate bugs). 
I can't help with the code but I can prepare such a summary (and if there are not enough people to help with testing I believe I can learn the basics of patches and builds in order to help - I've done make, make install once :).
bug 124123 also looks similar.
...and bug 177508, too.
(In reply to comment #91)
> bug 124123 also looks similar.
> 
Bug 124123 reported on Windows 2000. I guess it's different issue.

(In reply to comment #88)
> Dmitrii are you still in contact with those helpful developers? 

These developers are now on CC list of this bug

> If you are do
> you think it would save them time if we prepared a summary of this long thread
> (and some other's of duplicate bugs). 

I guess that would save some time not only for them, but also for us as well :)

Here is a summary[1]. It is in html (it has some pictures and some formating).
It took me many hours to complete but by writing it I came to look at things a lot more broadly with more details and from a more neutral point of view. I hope I've managed to write something that will help all who are interested to really understand all the issues. Of course I might very well got something really wrong. So don't hesitate to correct me. 

____________
[1] http://www.enlogic.gr/other/floss/mozilla_bug_69230.html
> b2) but if it's not, check what is the Latin character that would have been produced if the keyboard was in the English logical layout and act just as you would if [modifier] plus [that Latin character] was pressed

Wrong. If you have two groups "us(dvorak)" and "ru" (first and second groups correspondingly)  - then, with the current Russian group, you should check all groups (i.e. both Dvorak and Russian) for matching key. You should not look into "us(basic)" if it is not a part of your XKB configuration. 
So if you press Ctrl-Ы (Ы in Russian layout is mapped to the second key on right from Caps) - you should act as Ctrl-O if your first group is using "us(dvorak)", but you should act as Ctrl-S if your first group is using "us(basic)"
It means "forget the current group and scan characters of _all_configured_groups_".
@Nick:
Very nice work, but you have a mistake. Dvorak users (I use Dvorak, US-eng, and Hebrew layouts) want CTRL-Q to be cut, so that it is the same physical key as CTRL-X in US-eng. So problems 1 and 2 are the same: no matter what physical layout, the second key on the fourth row (X in US-eng, Q in Dvorak, ס in Hebrew) will cut.

Any Dvorak users disagree with me on this one?
@Sergey (comment #96)
> It means "forget the current group and scan characters 
> of_all_configured_groups_".

In what order should the scan take place?


@Dotan (comment #96)
> So problems 1 and 2 are the same: no matter what physical
> layout, the second key on the fourth row (X in US-eng, Q in Dvorak, ס in
> Hebrew) will cut.
> 
> Any Dvorak users disagree with me on this one?

Is this a voting challenge?

+1 for your opinion
  Originally, Ctrl+C tried to mimic mac's ergonomics
  (the [mac] key was comfortably close to 'C' key)
  So i suppose retaining the geometry of shortcuts
  might be better, from an ergonomic point of view.

Maybe we have to introduce a configuration param for it...


@Nick (comment #95)
Mprabo!
The landscape is now much better with your effort.

Hope you keep updating it with any newer opinions.

You may be interested to notify Gtk team about you doc.


(In reply to comment #98)
> @Sergey (comment #96)
> > It means "forget the current group and scan characters 
> > of_all_configured_groups_".
> 
> In what order should the scan take place?
In XKB configuration, groups are numbered from 1 to N (N<=4). Just walk from 1 to N - that would be the most natural thing. Of course, interesting things might happen in configurations with two or more groups having Latin characters (there is already open bug in gtk about it).
(In reply to comment #95)
> Here is a summary[1]. 

Nick, this is amazing. Thank you. 

Here is a helpful link to see what layouts are (possibly) affected by this bug: https://bugzilla.novell.com/show_bug.cgi?id=204402#c4

To quote:

Russia
Afghanistan
Bangladesh
Belarus
Bhutan
Bulgaria
Cambodia
Georgia
Greece
India
Iran
Iraq
Israel
Kazakhstan
Kyrgyzstan
Laos
Macedonia
Mongolia
Myanmar
Nepal
Pakistan
Sri Lanka
Syria
Tajikistan
Thailand
Ukraine
Arabic

Note that countries like Ukraine, Russia, Belarus and other Slavic countries  etc. use modified versions of Cyrillic layouts

Note also that you would have to walk through all layouts to find the correct mapping because "ru" or "ar" may very well come before "us" in layout list (see comment 72 and comment 73). This, however, needs to be done only if xkb doesn't provide any info on what physical keys were actually pressed (see comment 4 and comment 7, possibly)

OpenOffice used to have this issue, http://qa.openoffice.org/issues/show_bug.cgi?id=42122, but it's fixed now. Possibly code could be borrowd from them...
Dmitrii, from XKB you can get the keycode. Also, from XKB you can find out all keysyms (in all groups!) related to that keycode. That should be enough. As Havoc mentioned in comment #7) GTK caches that information (which is a good thing as long as you don't forget to keep the cache up-to-date).
@Anagnostopoulos
> Hope you keep updating it with any newer opinions.
I inded to allthough this thread might start accumulating comments faster than I can cope with (and there is always  REAL LIFE(TM) ready to get in the way just like now that I can't follow or the comments). 

> You may be interested to notify Gtk team about you doc.
I am not confident enough to do that. I have an almost zero programing background in Linux, Gnome and the likes. With what "credentials" will I show up?
@Dotan Cohen  Comment 97
I have updated the text with a "Stop press note" refering to your comment. I came to believe that Dvorak users most ofen have Ctrl + "the key marked with C in a Dvorak keyboard" triggering copy as a result of comment #35 from timeless. Do you have any experience from other applications/operating systems? Do you believe that some Dvorak users go for one option while other go for the other?

@everyone using Dvorak or some other than QWERTY Keyboard
PLEASE TELL US what is the norm in other programms you use. What key triggers "copy", "Cut", "Print" and the like. Is it the key at the same position as with QWERTY or is the Key with the same marking? Do you hit Ctrl+[the key with C on it] in order to Copy or do you press the 4th key of the 4th raw (the one that in Qwerty is labeled C).
(In reply to comment #102)
> @Anagnostopoulos
> > Hope you keep updating it with any newer opinions.
> I inded to allthough this thread might start accumulating comments faster than
> I can cope with (and there is always  REAL LIFE(TM) ready to get in the way
> just like now that I can't follow or the comments). 
> 
You could move it to wiki.mozilla.org, so that other people could help updating it. Also, people familiar with the technical details could then add the details to the wiki.

Other than VI (which I use in qwerty) other programs do as I described: they map accelerators to the same physical keys, no matter what layout is selected (EN, HEB, or Dvorak). I bothered to use Dvorak on a windows machine lately, and it also has this behaviour.

I'd also like to say thanks to Dmitrii and Nick for really getting the ball rolling now. Good work!
A relevant report from GTK+ and GNOME Bugzilla,

Multiple Latin layouts in XKB
http://bugzilla.gnome.org/show_bug.cgi?id=162726

In comment #7 in this (mozilla) report, it mentions that the GTK+ functionality for this issue is provided by a specific file, gtk/gtkkeyhash.c. The updated direct link to the source code is:
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkkeyhash.c?view=markup

There is a launchpad report for this as well, at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561

Dotan Cohen, Comment #105:
> Other than VI (which I use in qwerty) other programs do as I described: they
> map accelerators to the same physical keys, no matter what layout is selected
> (EN, HEB, or Dvorak). I bothered to use Dvorak on a windows machine lately, and
> it also has this behavior.

hmmm... this is getting weird. Other than windows what is the environment on which you're having the above experience? Also can you confirm the windows behavior again? The reasons I'm asking is that I've tried in Gedit and OOo under ubuntu 6.06 and then I've gone through the first 14 links of a Google search for "Dvorak Ctrl-C" and I've also searched OOo site for just "Dvorak". To summarize both my tests, all Google links[1] and the OOo links, suggest that ctrl-C and the likes change physical locations when you change from qwerty to Dvorak. Some of the links specifically mention Windows environments and some of them Linux. Most of them really emphasize on this matter because they cite it as one of the confusion-points when changing from qwerty to Dvorak - they don't just rush through the point. Many of the links are from strong proponents of Dvorak with many years of experience. Among those links it's the Wikipedia article regarding Dvorak keyboard[3] [7].

Here is the relevant snip from Wikipedia:

"""Keyboard shortcuts in GUIs for undo, cut, copy and paste operations are Ctrl (or Command) + Z, X, C, and V respectively; conveniently located in the same row in the QWERTY layout, but not on a Dvorak layout. [...]"""

Now regarding OpenOffice[5] I found the following bug report[6] which was both confirmed as a bug and was later fixed about two years ago:
"""I speak English, and use the Dvorak keyboard layout. When using OOo 2.0 [...] the keyboard shortcuts all are mapped to the QWERTY layout. i.e. If I press the CTRL + Dvorak "X", OOo interprets this as being
CTRL + "B" (note: the key representing "X" on the Dvorak keyboard represents "B" on the QWERTY keyboard). [...]
Also note, this problem does not occur in Windows XP on the same hardware with the same layouts."""
As you can see this user really expects to press Ctrl+ [Dvorak-"X"] in order to activate cut-to-clipboard. He doesn't expect to press Ctrl + [QWERTY-"X"]. And he says this is what happens in Windows. And the developers agree with him and fix the code in order for this behavior to occur. And it's been 2 years since then.

Now let's return to the Wikipedia article. There (and in one of the 14 Google links) the behavior you describe is *indeed* mentioned. But it's mentioned as a special feature that can be selectively enabled only in Macs:
"""The Mac OS offers an elegant solution: two Dvorak keyboard layouts are available on the Keyboard menu. The first, called simply Dvorak, remaps all the characters produced by a key (with and without modifier keys) from the old QWERTY key to the new Dvorak key. The second, called Dvorak QWERTY-Command remaps all the characters produced by the key-and-modifier combinations--except those in which the Command key is pressed] to the new Dvorak key; the Command-key variants are left the same as in the QWERTY layout."""[4]

Nick Demou
______________
P.S.
1. @Dotan, don't get me wrong. I didn't research this so much just to contradict you. I really want to clear the landscape of this bug and the expected behavior when using non-Qwerty layouts -and Dvorak in particular- seems to be the only thing that needs to be clarified before going to the devs and saying "here is the spec you should follow - it *is* The-Right-Thing-To-Do"

2. Things are getting... nasty[2] but I believe we can sort it out

______________
[1] to be precise, 2 or 3 of them don't really have anything to do
with the subject so I ignored them
[2] "Tech support, help! It's becoming a nightmare!" - Vanilla Sky - the movie
[3] http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard
[4] In fact this is one interesting idea for a way to handle our problem. Let's research and clear the landscape a little.
[5] There are only two bugs in OOo that have the word Dvorak in them. In one of them the reference is incidental. The other is the one I mention here. There is also no other mention of Dvorak keyboards except from one side-topic discussion in the mailing lists regarding the typing speed in Dvorak vs Qwerty. It seems that OOo users that type in Dvorak keyboards are happy with OOo's behavior
[6] http://www.openoffice.org/issues/show_bug.cgi?id=57297
[7] to be frank it was not the English Wikipedia page but I went on to read the English one
Nick,
If I can get access to that winbox again I'll double check. It was not one of the public university machines which we can change settings on. It might have been modified for all I know. Regarding Dvorak user's preferences, I think that it is very convienient having cut, copy, and paste near each other, and accessible via the left hand very easily. Other users may feel differently. And no, I don't think that you are trying to contradict me. Quite the opposite, you are trying to confirm my findings. As a good physicist should :)

Note that Kostis Anagnostopoulos seems to agree with my stance in comment #98. Any other Dvorak users out there?
I am very  disappointed from the attention Mozilla gives to this bug.

First of all, this bug was reported in 2001, and in any release Mozilla published since then, there isn't a fix for this bug.

Secondly, this bug isn't a "normal" bug (as the 'Severity level' suggests), since, it prevents from the user doing basic actions, like COPY, CUT and PASTE. Therefore, this bug should be flagged as a critical bug, that will be fixed in the nearest release.

I am hoping that you will consider the above, and fix this bug soon.
@Ofir:
Because there is an easy workaround (switching layout, or the extension fix), this is actually a minor bug:
"Minor:	minor loss of function, or other problem where easy workaround is present"

A critical bug is defined as "crashes, loss of data, severe memory leak", which this bug is not.

That said, I am also very disappointed in the attention that has been given to this bug. However, as Mozilla is open source, you can either try to fix the bug yourself or pay שוחד for someone to do it for you!
(In reply to comment #113)
> @Ofir:
> Because there is an easy workaround (switching layout, or the extension fix),
> this is actually a minor bug:
> "Minor: minor loss of function, or other problem where easy workaround is
> present"
> 
> A critical bug is defined as "crashes, loss of data, severe memory leak", which
> this bug is not.
> 
> That said, I am also very disappointed in the attention that has been given to
> this bug. However, as Mozilla is open source, you can either try to fix the bug
> yourself or pay שוחד for someone to do it for you!
> 

Ok, you are right. I will try the extension...

And just for the protocol, if I knew how to fix this bug, I would do it!
> this is actually a minor bug:
> "Minor: minor loss of function, or other problem where easy workaround is present"

AFAIK there are no workarounds for any of the languages listed in comment 100 except for Russian and (possibly)Greek and Hebrew

I would label this bug as "major: major loss of function" which it is
(In reply to comment #115)


> 
> AFAIK there are no workarounds for any of the languages listed in comment 100

The easy workaround is not the extension but the action of changing the keyboard layout, or otherwise (e.g. via mouse) accessing the commands linked to the accelerators.

> 
> I would label this bug as "major: major loss of function" which it is
> 

I believe most people do not consider accelerators in themselves a function, but rather an interface to functions. That is, it would be a "major loss of function" if this bug somehow prevented you from, say, copying marked text; but even with this bug, you still have three different ways to copy marked text (on most keyboards, there's ctrl+insert; you can switch layouts; you can use the Edit menu).

This bug is mighty annoying. There is a disturbing lack of proportion between, on one hand, the age and number of complaints, and, on the other, the amount of attention from developers until recently. But let us not lose our heads over it.

The above paragraph notwithstanding, I will appreciate it if one of the friendly developers who expressed interest in this bug (and are reading the correspondence) tries to mark this bug as blocking 3.0, or explain to us why it shouldn't be. I mean, come on. There are first-graders younger than this issue.
(In reply to comment #116)
> 
> I believe most people do not consider accelerators in themselves a function,
> but rather an interface to functions. That is, it would be a "major loss of
> function" if this bug somehow prevented you from, say, copying marked text; but
> even with this bug, you still have three different ways to copy marked text (on
> most keyboards, there's ctrl+insert; you can switch layouts; you can use the
> Edit menu).

Copy-paste is not the only accelarator in wide use.  
We often use Ctrl-Z, Ctrl+Y(Undo-Redo),Ctrl+N and Ctrl+T (New Window and Tab respectively), while there are pages designed to be used with content-accelarators (i.e. for data-entry web apps).
(In reply to comment #117)
> (In reply to comment #116)
> > you can switch layouts


> Copy-paste is not the only accelarator in wide use.  
> We often use Ctrl-Z, Ctrl+Y(Undo-Redo),Ctrl+N and Ctrl+T (New Window and Tab
respectively)

Just open any menu in Firefox and you'll see a list of shortcuts that don't work for any layout in comment 100

To quote a few: 

New window Ctrl+N
New tab Ctrl+T
Open location Ctrl+L
Open file Ctrl+O
Close window Ctrl+Shift+W
Close tab Ctrl+W
Save page Ctrl+S
Print Ctrl+P

That's from File menu alone.

And only a person who only uses English layout can suggest that "well, you can always switch layouts" as in comment 118. 

If you need to switch layouts for every darned little thing that the app supposedly does seamlessly whereas every other app in the system works ok without switching layouts, there's something wrong with the app.

I do urge someone who has the right permissions to change the bug's severity to major or even blocker.

Just a reminder. As of this post this bug is *6 years 6 months and 30 days old*
Flags: blocking1.9?
Flags: blocking1.8.1.8?
Dmitrii 'Mamut' Dimandt is right!

But, I think that replying here won't solve the problem. We need to inform the Firefox team manager about this bug, and maybe he will can help solve this bug.

BTW, why there isn't flag "blocking2.*"?


(In reply to comment #119)
> > Copy-paste is not the only accelarator in wide use.  
> > We often use Ctrl-Z, Ctrl+Y(Undo-Redo),Ctrl+N and Ctrl+T (New Window and Tab
> respectively)
> 
> Just open any menu in Firefox and you'll see a list of shortcuts that don't
> work for any layout in comment 100
> 

You are actually supporting my point: Program functions available accessible through accelerators are also accessible in other ways; there is no "major loss of function", unless you regard the accelerators themselves as a function -- which I, and I suspect many others, do not.

> 
> And only a person who only uses English layout can suggest that "well, you can
> always switch layouts" as in comment 118. 
> 

No. I use Hebrew and English. I find myself switching for accelerators, or using the mouse more than I'd like to, and I'm certainly annoyed by it (or else I wouldn't be on this bug). I just don't go ballistic over it.

> If you need to switch layouts for every darned little thing that the app
> supposedly does seamlessly whereas every other app in the system works ok
> without switching layouts, there's something wrong with the app.
> 

And I didn't claim otherwise. All I said was that you cannot convincingly claim a major loss of function. You can certainly claim a major aggravation, and in that I join you whole-heartedly.

> I do urge someone who has the right permissions to change the bug's severity to
> major or even blocker.
> 
> Just a reminder. As of this post this bug is *6 years 6 months and 30 days old*
> 

Not only do I agree that the bug should be marked a blocker purely for reasons of age -- I already said so, in comment #116.

(In reply to comment #121)
> (In reply to comment #119)

> > And only a person who only uses English layout can suggest that "well, you can
> > always switch layouts" as in comment 118. 
> > 
> 
> No. I use Hebrew and English. 

You still need to realise not everyone is in your case, some users do not have US (Intl) configured *at* *all*, because they do not use primarily latin text, or if they do their target latin language is not English, so their latin access can be anything from third and fourth-level keys to another - not US (Intl) - layout as second or third layout.

So Dmitrii is perfectly right you're not the worst-case user at all. You have US (Intl) configured and you use it regularly.
>  I find myself switching for accelerators, or using the mouse more than I'd like to

we could mark it critical solely for accessibility reasons :)

> All I said was that you cannot convincingly claim a major loss of function.

Too bad this bug only affects Linux. Because I believe I've seen preinstalled OEM Windows' with only ru enabled on them... 

> Not only do I agree that the bug should be marked a blocker purely for reasons
of age -- I already said so, in comment #116.

Right. Sorry, with all the comments in the discussion it's not too hard to ovelook one or two :)

------
> so their latin access can be anything from third and fourth-level keys to another - not US (Intl)

Actually this is true for users in Cyrillic regions - they can easily have e.g Russian and Ukrainian installed alongside English. Switching from Russian to English may involve two keystrokes instead of one - just to execute a Ctrl+C!

------

I've found one more thing... Some newer bugs have flags like blocking‑firefox2, blocking‑firefox3 (thanks Ofir in comment 120). This one doesn't... I'm afraid this bug cannot and will not be seen by too many people. WHo knows, this bug might have been dumped a couple of years ago... Should we post a new bug marked as blocking-firefox2 with a link here just in case?
(In reply to comment #123)
> I've found one more thing... Some newer bugs have flags like
> blocking‑firefox2, blocking‑firefox3 (thanks Ofir in comment 120). This one
> doesn't... I'm afraid this bug cannot and will not be seen by too many people.
> WHo knows, this bug might have been dumped a couple of years ago... Should we
> post a new bug marked as blocking-firefox2 with a link here just in case?
> 
Yes, indeed.

But, be aware, they probably will close the bug and mark it as duplicate of this bug, as they did to a bug I reported two weeeks ago (https://bugzilla.mozilla.org/show_bug.cgi?id=394997).


I've created a new bug report outlining the problem and some details in bug 396409 including a plea not to close the bug as duplicate until the issue has been resolved.

Let's wait and see :)
Attached file bugspam, ignore me (obsolete) (deleted) — 
debug
Attachment #281426 - Flags: superreview?
Attachment #281426 - Flags: review+
Attachment #281426 - Flags: approval1.9?
Attachment #281426 - Flags: approval1.8.1.8?
Attachment #281426 - Flags: approval1.8.1.7?
Attachment #281426 - Flags: approval1.8.0.14?
Attached file bugspam, ignore me (obsolete) (deleted) — 
debug
Attachment #281427 - Attachment is obsolete: true
Attachment #281427 - Attachment is patch: false
Attachment #281427 - Attachment mime type: text/plain → image/bmp
Attachment #281427 - Attachment description: patch → spam image
Attachment #281426 - Attachment description: patch → spam image
Attachment #281426 - Attachment is obsolete: true
Attachment #281426 - Attachment is patch: false
Attachment #281426 - Attachment mime type: text/plain → image/bmp
Attachment #281426 - Flags: superreview?
Attachment #281426 - Flags: review+
Attachment #281426 - Flags: approval1.9?
Attachment #281426 - Flags: approval1.8.1.8?
Attachment #281426 - Flags: approval1.8.1.7?
Attachment #281426 - Flags: approval1.8.0.14?
Attachment #281426 - Attachment description: spam image → bugspam, ignore me
Attachment #281426 - Attachment is patch: true
Attachment #281426 - Attachment mime type: image/bmp → text/plain
Attachment #281426 - Attachment is patch: false
Attachment #281426 - Attachment mime type: text/plain → image/bmp
Attachment #281427 - Attachment description: spam image → bugspam, ignore me
This very old bug is not a stop-ship for the security releases, obviously we've lived with it for years. Once this has been checked in and tested on the trunk (Firefox 3 code) we can look at approving it for some future branch release.
Flags: blocking1.8.1.8? → blocking1.8.1.8-
(In reply to comment #129)
> This very old bug is not a stop-ship for the security releases,

I agree,

> obviously we've
> lived with it for years. Once this has been checked in and tested on the trunk
> (Firefox 3 code) we can look at approving it for some future branch release.
> 

But this attitude is quite disappointing. What everybody here wants, with asking for a "blocking" mark, is to make sure Firefox 3 (and 2.1, if there is one) includes a solution to this bug. What you basically say is -- if I understand correctly -- Nobody will be forced to solve it until it's solved.

Or am I misunderstanding?

You're missing the fact that I'm only managing the Firefox 2.0.0.x releases and left the FF3 nomination alone, but in general the number of "wanted" fixes greatly exceeds the available bug-fixing effort. You need to make a persuasive case that fixing this bug is more important than whatever bug won't get fixed in its place, or you need to increase the bug-fixing bandwidth by finding someone new to provide the patch.
(In reply to comment #131)
> You're missing the fact that I'm only managing the Firefox 2.0.0.x releases 
> and left the FF3 nomination alone,

Yes, sorry.

> but in general the number of "wanted" fixes
> greatly exceeds the available bug-fixing effort.

I'm sure everybody is aware of this. Indeed, the blocking request was mostly a request to prioritize this bug.

> You need to make a persuasive
> case that fixing this bug is more important than whatever bug won't get fixed
> in its place,

The main argument is 6.5 years of annoyance for a large class of users.

> or you need to increase the bug-fixing bandwidth by finding
> someone new to provide the patch.
> 

A patch was added to this bug about four months ago, but your earlier comment implied unwillingness to help it into the source (which I now realize is probably simply not your job). 
(In reply to comment #131)
> You need to make a persuasive
> case that fixing this bug is more important than whatever bug won't get fixed
> in its place, or you need to increase the bug-fixing bandwidth by finding
> someone new to provide the patch.

In addition to Shai's reply, I think that being at place 114 in terms of number of votes out of thousands of bugs for so long must also speak something about the seriousness of this bug.

Then again - I'm aware after your clarification that it's not your domain.

(In reply to comment #129)
> This very old bug is not a stop-ship ... obviously we've
> lived with it for years.

Daniel, I should you realize this kind of cynical comment is an invitation to massive flaming. People have waited politely for years for this problem to be resolved. You're basically telling them "since you didn't make a stink of it before, and let us ship releases without fixing our bug, we consider you don't really care about it"

A bug age should *never* be taken as a severity indication. That practice is just an incitation to developpers not to answer bugs (since delaying results in magical severity downgrading), and an incitation to users to public lynching (since letting developpers take their time is taken as lack of interest). Do you really want to promote this kind of relations?

> You need to make a persuasive case that fixing this bug is more important than whatever bug won't get fixed in its place

See comment 100 for a list of users that are affected by this bug and have been affected by it for the past 6.5 years.

This bug affects the core, not just Firefox. The entire product line is affected. 

Also note that Mozilla software are currently the only Linux apps I'm aware of that exhibit this behavior. Especially among the more popular ones.

If anything, it hurts Mozilla from marketing standpoint ;)

If it doesn't get fixed now, when will it be fixed? With all the major things that are brewing in Mozilla (moving exclusively to XULRUnner, reducing memory consumption, possible foray into mobile devices after memory requirements have been fixed and who knows what else). 


I see that this bug is assigned to Aaron Leventhal and he is not on the CC list. Does that mean that the only person who took responsibility for this bug is ignoring it? If so, then I will contact Aaron and kindly request that he either assume the responsibility that he took upon himself, or that he relinquish that responsibility.
(In reply to comment #136)
> I see that this bug is assigned to Aaron Leventhal and he is not on the CC
> list. Does that mean that the only person who took responsibility for this bug
> is ignoring it? 

No, you don't need to be on the CC list, if the bug is assigned to you - you're still getting bugmail (including useless and/or cynical comments).
Good to know, thanks.

In that case: Aaron! We need you!!! Please pop in and let us know what's going on! Thanks!
The content of attachment 281426 [details] has been deleted by
    Gervase Markham <gerv@mozilla.org>
who provided the following reason:

Porn

The token used to delete this attachment was generated at 2007-09-29 08:46:38 PDT.
The content of attachment 281427 [details] has been deleted by
    Gervase Markham <gerv@mozilla.org>
who provided the following reason:

Porn

The token used to delete this attachment was generated at 2007-09-29 08:46:55 PDT.
(In reply to comment #134)
> (In reply to comment #129)
> > This very old bug is not a stop-ship ... obviously we've
> > lived with it for years.
> 
> Daniel, I should you realize this kind of cynical comment is an invitation to
> massive flaming.

That is not a cynical comment. I'm trying to usher out a release containing several security fixes. That is my priority, and I'm not going to delay users getting those fixes waiting for a bug that is annoying a lot of people but which is not making any progress. I do not have the power to make people fix things, I have to make the best of what I've got.

I am truly sorry that I can't personally help out here.

> People have waited politely for years for this problem to be resolved.

That is rarely effective, I'm sad to say. I'm not recommending rudeness or abuse, but "the squeaky wheel gets the grease."  Programmers gravitate to the things that interest them, and avoid the unfamiliar since they're less effective there and won't fix as many bugs for the same amount of effort. Their managers aren't going to direct them otherwise if they don't realize there's a problem. And knowing that there's a large problem will attract some developers who want to be the here. Don't wait politely, wait actively and persistently.

And PLEASE, do not advocate in the bug. That will, if anything, repel developers who just want to get work done and don't want to be tangled up in controversy. Beyond CC's, Votes, and explaining the problem (all done here), you need to get attention outside the bug. In the localization newsgroups, in the support feedback groups, tell your country's localizers and have them bug the Mozilla folks coordinating localizations, get on IRC and tell developers about it, mail the marketing people -- if anyone should be caring about "annoyed" people it's them!

As the security release coordinator I'm extremely risk averse -- the last thing I want is people turning off the automatic updates because they break things. We can't wait for an actual release to get testing, and nearly all of our volunteer testers are using pre-Firefox 3 nightly versions rather than the boring old Firefox 2 updates. I really wish we had more testers on the Firefox 2 branch, but I can't make people test things any more than I can make them write patches. Changes must go into the Firefox 3 ("trunk") codebase first, and after the fix has proven itself in daily use we can look at taking it in a Firefox 2 version.

A patch is a good first step, but it'll need reviews, and then someone to check it in (the latter can be accomplished with the "checkin-needed" keyword, after it's been reviewed and approved by the right module owners).

removing aaron as the assignee, looks like someone else assigned it to him, there's no evidence he intends to fix this (it's "NEW" rather than "ASSIGNED") and having an assignee appears to be giving people false hope.

Since the patch is in gtk2 widgets http://www.mozilla.org/owners.html says roc should approve this or delegate to a peer.
Assignee: aaronleventhal → nobody
Attachment #267004 - Flags: review?(roc)
Stumbled. Quite a few people should see the bug now.
This gnarly bug calls for Karl's ninja skills.

However we fix this, it's going to be fragile, so I doubt we will ever fix this on the 2.0 branch. However, if we come up with a 3.0 fix it could probably be backported by distros if desired.

> http://www.enlogic.gr/other/floss/mozilla_bug_69230.html

Thank you for that.

It seems to me that we should just hew to whatever GTK does now rather than take this patch.
roc:
> > http://www.enlogic.gr/other/floss/mozilla_bug_69230.html
> Thank you for that.

just my 2 cents. If you (or anybody else) has any idea of anything else I could do without learning GTK and how to use some linux programming programmers tool chain I'll be glad to help (I'm just to old to compile'n'link but I'm to young to die)
A brief explanation of the attachment deletions:

We've had problems in the past with people using Bugzilla as a porn or spam image server; so when a new account is created and attaches girlie pictures to random bugs they have no connection to, we tend to assume that's what's going on. I got an emailed complaint from someone, and investigated. It seemed pretty clear cut (for the reasons given above), so I checked with Dave Miller and then deleted them. "Porn" was a shorthand, not a legal category.

It turns out that after uploading they were used as testcases for other bugs; apologies for any inconvenience the deletions caused.

Gerv
Flags: blocking1.9? → blocking1.9+
The attached patch fixes the problem for me, the algorithm is:
 if modifier key is pressed (Ctrl, Alt, Meta) and pressed key is not latin (english), then search all keyboard groups for latin key which may be used as a shortcut key.

Have I missed something? Please review and comment.
Attachment #284450 - Flags: review?
Thanks Oleg, your description of the algorithm seems OK - how can we test it in real life? 
I create small patch. I hope many people test it and write about my errors. I need review from roc@ocallahan.org. I works with firefox 2.0.0.7. I test it with 2 languages (eng+rus) and only with rus.
I am very glad to see that someone wrote a patch to fix this problem!
Thank you Oleg Krylov and bUg.!

It will be included in the next release? (maybe Firefox 3?)
Oh, I see that my patch is similar to amnonaar@gmail.com patch. Patch from Oleg Krylov is more effectively, but if english language always on group 0, level 0, my patch is more smaller :). I think english always on 0-0, cause i test with only 1 system language (russian) and it works. May be i wrong, please send me sample config when english not on 0-0. Thanks.
Attachment #284457 - Flags: review?
> if english language always on group 0, level 0,

Wrong assumption, generally speaking. Configuration 'ru,us' is perfectly valid
Requesting review without specifying the reviewer makes the request likely to get lost. See http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree#Getting_the_patch_reviewed

(In reply to comment #151)
> > if english language always on group 0, level 0,
> 
> Wrong assumption, generally speaking. Configuration 'ru,us' is perfectly valid
> 

But with configuration ru,us on my computer it works.
It means your patch does not require latin characters to be in group 0;)
(In reply to comment #154)
> It means your patch does not require latin characters to be in group 0;)
> 

In system configuration no, but result from function gdk_keymap_get_entries_for_keycode gives me latin on 0,0 always (and another 3 languages, but in system i have only 2, may be it's bug :) )
Attachment #284457 - Flags: review? → review?(roc)
How about we just go with Oleg's patch? It looks pretty good to me.

+            if (!(GDK_0 <= event.charCode && event.charCode <= GDK_9) &&
+                !(GDK_A <= event.charCode && event.charCode <= GDK_Z) &&
+                !(GDK_a <= event.charCode && event.charCode <= GDK_z)) {

What about Latin punctuation like -, = etc which are also used for accelerators?

+                        if ((GDK_0 <= keyvals[n] && keyvals[n] <= GDK_9) ||
+                            (GDK_A <= keyvals[n] && keyvals[n] <= GDK_Z) ||
+                            (GDK_a <= keyvals[n] && keyvals[n] <= GDK_z)) {

Probably should share code with the previous test, using an inline function.
(In reply to comment #156)

> What about Latin punctuation like -, = etc which are also used for
> accelerators?

They should be killed.

Many latin layouts do not put those at the same place than the US layout, sometimes they're on second not first level, and you can not just test all the level inconditionaly because a latin layout can have two punctuation signs which are on separate keys for US (intl) on the same key.

Any accelerator that uses latin punctuation is broken by design
OK, but Web pages can specify punctuation accelerators, so we have to do the best we can when that happens. (Also Firefox uses Ctrl or Cmd = and - for text zooming, although localizers can change that.) So I'd like the patch to address thats somehow, even if it's just a comment that says "we don't try to fix up punctuation accelerators here".
(In reply to comment #158)
> even if it's just a comment that says "we don't try to fix up
> punctuation accelerators here".

Yes, please! This is the sort of corner case that can bog that bug down in the mud again. Just get the show rolling and break this part down to a separate bug or something.

Thanks for taking care of it.

Actually, CTRL-"-" and CTRL-+ are two shortcuts that I use constantly. My 1680x1050 laptop display has such high resolution that the default text size of most websites is unreadable. This case should _not_ be a separate bug. Separate bugs are for separate problems, not for "this is hard, so I won't do it" cases. Note that with the Russian Hotkeys extension, these two hotkeys work fine for me in Hebrew.

That said, I very much appreciate Oleg and everybody else's efforts. Thanks!
Thank you for the patches, people.

Step b1 of the algorithm at http://www.enlogic.gr/other/floss/mozilla_bug_69230.html is being skipped, but that step is (too) hard.

The problem with this is that, because menu access keys are localized, removing the non-latin character codes will inhibit opening the menus in some locales.

However, I think we can make some guesses:
Although menu access keys are localized, accelerator keys seem to still have latin assignments (which might be argued as the cause of the problem).
See mozilla-firefox-2.0.0.7-el.xpi/chrome/locale/browser/browser.dtd for example.

As far as i can see menu access keys are only used with the Alt modifier and (latin) accelerators only with Control, so doing the mapping for event.isControl only could work for the accelerators.

(Getting the menu access keys working for all groups/layouts is another issue...)

(In reply to comment #160)
> Actually, CTRL-"-" and CTRL-+ are two shortcuts that I use constantly. My
> 1680x1050 laptop display has such high resolution that the default text size of
> most websites is unreadable.

I also zoom constantly (thanks nosquint) but those accelerators are totally useless to me: on French standard layout + is next to backspace on second level, - on first level on 6, and you don't have any keypad +- on a laptop.

No French user is going to configure a second latin layout just so US-centric accelerators work

Unlike letters, you can't assume punctuation signs will have a nice key just for them as long as a latin layout is configured somewhere

(In reply to comment #160)

First of all, thanks to patchers and Mozilla developers for the late activity on this problem.

Dotan, no Hebrew layout I'm aware of changes the meaning of the latin '-' and '=' keys -- and in fact, Ctrl-'-' and Ctrl-'+' work fine in Hebrew without any extension. Does Dvorak change them? 

While separate bugs are 
> not for "this is hard, so I won't do it" cases
they may certainly be used for 'this part of the bug has different priority than the other part of the bug'. I claim that the punctuations, because of the problems noted in comment #157, and because in many layouts they are placed in the same positions, are a much lower priority.

I would favor a solution that handles punctuations too over one that doesn't (actually, more for Software Engineering reasons than Product Management ones, as a solution which doesn't take care of them is probably more hackish than one that does). However, I wouldn't block FF3 waiting for one. And the mechanism to express these preferences is separate bugs.



(In reply to comment #162)
> (In reply to comment #160)
> > Actually, CTRL-"-" and CTRL-+ are two shortcuts that I use constantly. My
> > 1680x1050 laptop display has such high resolution that the default text size 
> > of most websites is unreadable.
> 
> I also zoom constantly (thanks nosquint) but those accelerators are totally
> useless to me: on French standard layout + is next to backspace on second
> level, - on first level on 6, and you don't have any keypad +- on a laptop.

I'm a NoSquint user as well. How do you zoom text when you are in the French layout? I do not understand your objection. Are you objecting to the patch's modification of symbols or not? On what basis? Are you saying that the default French layout is not convienent for keyboard text zoom, so you prefer the alternative layout? Do you use one keyboard layout (French) for some operations (copy, paste) and a different layout for others (text zoom)?

> No French user is going to configure a second latin layout just so US-centric
> accelerators work

I would not expect that. The French being what they are! [1]

> Unlike letters, you can't assume punctuation signs will have a nice key just
> for them as long as a latin layout is configured somewhere

That's not my assumption. My assumption is that users will want to have the same keyboard accelerators in all layouts. It _seems_ that you do not. Please clarify if this is your case. I believe that this bug is for those who _want_ the same accelerators regardless of layout (see bug title), so if you need different accelerators for different layouts, this isn't the place. I'm not being rude, I'm just trying to help you achieve the accelerator behaviour that you need.

[1]: That is a joke. I actually admire the French resistance to foreign influence, especially with regard to language and culture.
(In reply to comment #160)
> Actually, CTRL-"-" and CTRL-+ are two shortcuts that I use constantly. My
> 1680x1050 laptop display has such high resolution that the default text size of
> most websites is unreadable. This case should _not_ be a separate bug. Separate
> bugs are for separate problems, not for "this is hard, so I won't do it" cases.
> Note that with the Russian Hotkeys extension, these two hotkeys work fine for
> me in Hebrew.
I appreciate your concern but please scroll up and look at the history of this bug  - good working patches and suggestions have been dropped before that could have solved 80+% of the problems for 99% of the people here if implemented. If your request is accepted then you can start thinking of a Bar-Mitzva present (that's 13th birthday) if not a wedding present for this bug.

If you can come up with working logic or a patch then I'm all for going with it but otherwise let's get this train out of the station at last.

> Dotan, no Hebrew layout I'm aware of changes the meaning of the
> latin '-' and '=' keys -- and in fact, Ctrl-'-' and Ctrl-'+' work
> fine in Hebrew without any extension. Does Dvorak change them? 

This machine has no Dvorak, but when I get home I'll check. I don't think that is does, though.

I also agree with Amos. Let's get 80% of the problems fixed for 99% of the people, then we'll file bugs on what's left. I assume that I'll be one of those 20% left filing bugs, but no bother. I'm here doing it now anyway...
(in reply to Comment #161)

karl paraphrased to give a synopsis:
"Step b1 of the algorithm at .../.../mozilla_bug_69230.html is being skipped.
As a result when pressing [alt]+[non-latin-letter] the non-latin character code
will be replaced by a latin one. But [alt]+[non-latin char] is often used to
activate a menu entry. So by omitting step b1 we will inhibit opening the menus
in some locales."[1]

Karl notes that step b1 is hard (probably too hard) and proposes as a
workaround to skip step b1 but also *not* to triger the algorithm for
[alt]+[key]. 

This workaround seems OK expect from one detail: it means that pressing
[alt]+[key] while in a latin logical keyboard layout will not be discarded in a
localized mozilla that expects [alt]+[non latin char] to trigger an action.
This is a tricky issue[2] so I suggest that we should check two other
possibilities

a) reexamine how hard step b1 is
b) produce both the translated-to-latin and the untranslated key events for
every [modifier]+[non-latin-char]

______________________
P.S. after all this comments what this bug relly means to me is that thinking
about [modifier]+[character code] instead of [modifier]+[key code] is so wrong
that it leads to a lot of confusion and a lot of problems. It's important that
at some point all talks / specs / code / whatever regards hot-keys be using the
[modifier]+[key code] idea.

[1] Karl, you surely understand my algorithm better than I do :)
[2] I would expand on the subject if RealLife was not pushing me that hard

(In reply to comment #164)

> I'm a NoSquint user as well. How do you zoom text when you are in the French
> layout?

If you are a desktop user you use the numpad +-
If you're a laptop user, either you travel with a separate bulky usb keypad or wheel mouse, or you click on Nosquint and enter zoom level manually

> I do not understand your objection. Are you objecting to the patch's
> modification of symbols or not?

I'm not objecting to the patch I'm objecting to the idea the same kind of patch can be used to fix punctuation accelerators. Punctuation placement on layouts is a lot more random than letter placement, even on latin layouts, so it should not be used in accelerator period.

With a letter you always have a and A on the same key, and b B on another (as long as a latin layout is configured). So you can assume "I can have an accelerator with a or A, and an accelerator with b or B, they'll always exist and never collide, and thay'll be in a convenient place". With + and - you can not assume they'll be on separate keys, or on the same keyboard level, or that - will exist in a convenient position at all (non-shell users typically only need minus, which is at another unicode point than ascii hyphen)

With a punctuation mark you can have two punctuation marks which are on separate keys in US layout on the same key, or some can not be available altogether because the've been replaced by correct unicode (not ascii) points, or one may be on Caps and the other not.

> Are you saying that the default
> French layout is not convienent for keyboard text zoom, so you prefer the
> alternative layout? Do you use one keyboard layout (French) for some operations
> (copy, paste) and a different layout for others (text zoom)?

No I'm saying I don't use punctuation accelerators at all because they assume similar punctuation placement as on US layout and I'm not going to install and learn a separate latin layout just so a few mozilla accelerators work.

> > No French user is going to configure a second latin layout just so US-centric
> > accelerators work
> 
> I would not expect that. The French being what they are! [1]

It's not a question of being French or not. When you have a non-latin locale installing a latin layout as alternative is useful because you sometimes need to type latin text. As a side effect this alternative can be used to make latin letter accelerators work.

When your primary layout is already latin you don't need a secondary latin layout to type latin text, and accelerators are not a sufficient reason by themselves to install it. So any accelerator that does not work for every latin layout out there (every punctuation accelerator) can not be managed through the fallback method defined in this bug. The fallback method discussed here works because every user will have some access to latin letters to type URLs.

> > Unlike letters, you can't assume punctuation signs will have a nice key just
> > for them as long as a latin layout is configured somewhere
> 
> That's not my assumption. My assumption is that users will want to have the
> same keyboard accelerators in all layouts.

For accelerators that can be sanely handled this way ie letter accelerators. Punctuation accelerators are not the same case at all.

(In reply to comment #167)

> P.S. after all this comments what this bug relly means to me is that thinking
> about [modifier]+[character code] instead of [modifier]+[key code] is so wrong
> that it leads to a lot of confusion and a lot of problems. It's important that
> at some point all talks / specs / code / whatever regards hot-keys be using the
> [modifier]+[key code] idea.

It's not, don't confuse dvorak people demands with the demands of other non-us-qwerty people.

Dvorak people can demand to treat accelerators as if the layout was really qwerty. Because they live in a qwerty world, usually have qwerty printed on their layout, etc.

For a person that lives in a latin country that historically had its own latin layout, where every keyboard serigraphy follows this layout, qwerty placement makes no sense at all.

(plus key_codes are not arranged physically the same way in every hardware keyboard out there)
2nd try of my patch, the logic is the same, except:
I moved latin shortcut key detection to separate inline function ass suggested by Robert
added comment about punctuation shortcuts, we don't address them in this patch because punctuation symbols normally exists in all layouts (on different keys probably but still), but the bug is more about keys which don't exists in one layout but exist in latin layout (e.g. latin keys and russian layout), so shortcut can't be used without switching layouts.
I also added a check in a patch to look only for keys from different layouts (groups), so that we don't try to change user pressed key inside one layout.

Any other ideas/comments?
Attachment #284450 - Attachment is obsolete: true
Attachment #284606 - Flags: review?(roc)
Attachment #284450 - Flags: review?
Both patches by Oleg were tested for the Greek language by users of the ADSLGR.com forum. A translation/summary,

a. both firefox and thunderbird managed to build succesfully
b. tested both with English UI and Greek for Firefox
c. Sunbird failed to build, due to compilation errors with pango/cairo (using GNOME 2.20 libraries)
d. the layout tested was "us,gr"

Reference: http://adslgr.com/forum/showthread.php?t=137813
(In reply to comment #161)
> The problem with this is that, because menu access keys are localized, removing
> the non-latin character codes will inhibit opening the menus in some locales.

It looks the Alt-key behavior has changed on Windows in bug 287179 to find the corresponding latin key.  I've filed bug 399939 to discuss the best behavior.
Depends on: 399939
(In reply to comment #167)
> ... so I suggest that we should check two other
> possibilities
> 
> a) reexamine how hard step b1 is

We would need to keep all our keybindings in one place that could be queried.
Probably a good idea but probably much harder than what has been suggested here.

> b) produce both the translated-to-latin and the untranslated key events for
> every [modifier]+[non-latin-char]

It also sounds a possibly sensible idea to first send one event, and, if that is not handled, the try another, but this would involve much testing as there is likely code that does not consider such a situation.

The approach taken in the patches here is not far from what is done on MS Windows.  Mimicking the Windows implementation gives us the best chance of localizations working best on all platforms.
_gtk_key_hash_lookup is worth comparing in lines 369-402 of:

http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkkeyhash.c?annotate=14541

We don't have the luxury of a key_hash to search but the !have_exact path is
relevant.  It does a couple of things differently: with level and
consumed_modifiers.

gtk only matches when the level is the same:

If a user has tried to type Ctrl-* on a US QWERTY keyboard, it may be a bit
surprising to have it mapped to a Ctrl-8 because there is a Greek or US Dvorak
layout for example.  Checking the level may be even better than the check on
the same group.  I'm not sure how Caps Lock affects things here - if it does
then some logic with isShift may be required.

consumed_modifiers is used in testing the modifiers:
http://developer.gimp.org/api/2.0/gdk/gdk-Keyboard-Handling.html#gdk-keymap-translate-keyboard-state

I don't know whether we need to worry about this or not.  A situation where
this could be useful is if a Ctrl or Alt is required to get a different
character on a key, in which case we wouldn't want to treat that modifier as
activating a command or access key.  Do any keyboard layouts use Ctrl or Alt
to select a different character?

Meta may select a different character too, but is there any reason to do the mapping for meta?

Punctuation:

I know punctuation is difficult and localizers may have to correct for
problems with punctuation command keys, but I wonder if we can do better.  If
a user tries Ctrl-+ on a Belgian AZERTY keyboard, it would be inconvenient to
map that to Ctrl-Z because there happens to be a US Dvorak layout (for
example).  I think checking whether the keyval is + or - at least before
searching for a latin value would be better.  I think this is closer to the
Windows behavior in MapFromNativeToDOM and OnKeyDown (but I don't completely
understand what's happening there, or how virtual-key codes are assigned):

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow.cpp&rev=3.711&mark=3108-3116,3320-3323#3110

One last nit: restoring aEvent to its original state seems the right thing to
do given that this function may return false, but I prefer to make a copy
where practical rather than modifying and restoring.  I know it was being
modified before your patch, but here's an opportunity to tidy this up.  This
would also avoid the confusion with two nested "savedKeyval" variables.  (I
don't know why the existing code only restores from savedKeyval sometimes:
that shouldn't be necessary with a copy of aEvent - and I'm a bit sceptical
as to why the level should be changed for non-alpha charCodes too, but let's
not worry about that now.)

(In reply to comment #175)

> Punctuation:
> 
> I know punctuation is difficult and localizers may have to correct for
> problems with punctuation command keys, but I wonder if we can do better.  If
> a user tries Ctrl-+ on a Belgian AZERTY keyboard, it would be inconvenient to
> map that to Ctrl-Z because there happens to be a US Dvorak layout (for
> example).

AZERTY is a latin layout, the probability of the user configuring another latin layout like US qwerty is close to nill (he may configure a French dvorak layout which is not the same as the US one)

> I think checking whether the keyval is + or - at least before
> searching for a latin value would be better.

You're already in the latin layout. latin ≠ US qwerty

> and I'm a bit sceptical
> as to why the level should be changed for non-alpha charCodes too

If you ignore the fact other latin layout may not have punctuation on the same level as US qwerty (and that this level is not uniform for all punctuation signs) your implementation won't work
Whiteboard: [has-patch]
Priority: P3 → P5
Just wonderful, tested 3.0 beta 1 or how is it named -- not working.
You wanna tell me that they didn't applied the patch?!

And now I noticed that they marked the bug as P5 instead as P3 (lower priority!)
This bug is not marked FIXED, and the patch has not even been reviewed yet.  This bug has enough comments, please refrain from adding more comments unless you are fixing the bug.

(In reply to comment #176)
> AZERTY is a latin layout, the probability of the user configuring another latin
> layout like US qwerty is close to nill (he may configure a French dvorak layout
> which is not the same as the US one)
> 

How did you calculate that probability? I personally have two different Latin layouts on this machine. Have you ever tried to program in Dvorak?
Just spent all my technical life working with French AZERTY users none of whom had a backup qwerty layout just so qwerty-centric logic worked.

Of course I may have missed one or two but that would not even make 1°/oo
P5 --- least important, milestone --- future (distant, I guess).  At least 2 patches, both unreviewed.  Open for almost 7 years, almost 200 comments.  I really **** wish I could ditch Firefox.

For those of you who think it is a "minor loss of functionality", I suggest modifying Firefox so that toolbar is always hidden and accessing menu requires 2 additional clicks of the mouse.  Making 2 extra clicks will be just an easy workaround, why bother?

(In reply to comment #182)
> For those of you who think it is a "minor loss of functionality", I suggest
> modifying Firefox so that toolbar is always hidden and accessing menu requires
> 2 additional clicks of the mouse.  Making 2 extra clicks will be just an easy
> workaround, why bother?
> 
Isn't that what Microsoft did with Internet Explorer 7? Hidden menus is the next revolution. Go go Microsoft. ;-)


I think we could take Oleg's patch if someone addresses Karl's comment #175 about checking for the same level.
(In reply to comment #184)
> I think we could take Oleg's patch if someone addresses Karl's comment #175
> about checking for the same level.
> 

In that comment Karl mentions things that _might_ go wrong, not actual problems. That should not stop the process. Lets get going and if Karl's concerns turn into issues then we will deal with them.
We should try to address potential problems now. If Oleg isn't around anymore and no-one else steps up, then as a last resort I will consider the patch as is. But only as a last resort.
Robert, there will always be potential problems. The real problems are only discovered by forging forward. Some of the potential problems may turn into real problems, and some won't. Unforseen real problems will crop up. That's called life. Forge ahead.
Try 3.

Now I've addressed Karl's comments from Comment #175. In the patch I now check if levels are the same, and don't modify aEvent, but rather make a copy of it in tmpEvent.

As always comments are welcomed.
Attachment #284606 - Attachment is obsolete: true
Attachment #289837 - Flags: review?(roc)
Attachment #284606 - Flags: review?(roc)
Comment on attachment 289837 [details] [diff] [review]
look for latin key if modifier is down [try3]

great!
Attachment #289837 - Flags: superreview+
Attachment #289837 - Flags: review?(roc)
Attachment #289837 - Flags: review+
Attachment #289837 - Flags: approval1.9?
Attachment #289837 - Flags: approval1.9? → approval1.9+
Assignee: nobody → oleg.krylov
Thanks, Oleg!
Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.237; previous revision: 1.236
done
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed, helpwanted
Resolution: --- → FIXED
Whiteboard: [has-patch]
Target Milestone: Future → mozilla1.9 M10
So, does it mean now that all is needed for the patch is to make it into the trunk?

Yay!!!! :)
(In reply to comment #192)
> So, does it mean now that all is needed for the patch is to make it into the
> trunk?

It's already on the trunk, as per comment #191.
Hurrah!

Yay!

You guys are the best! :)
Keywords: intl
Blocks: 405213
Great Job!

I'm very glad that this 6-years bug was solved. Finally!
Backport plz. to  rv:1.8

I am waiting this fix five year!!!
Flags: blocking1.8.1.9?
I get the following errors in my Error Console now. Not sure if it's a regression from this patch, but I haven't noticed them before:

Warning: Key event not available on GTK2: key="b" modifiers="accel,shift"
Source File: chrome://browser/content/browser.xul
Line: 0

Warning: Key event not available on GTK2: key="a" modifiers="accel,shift"
Source File: chrome://browser/content/browser.xul
Line: 0

(they repeat two more times)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112404 Minefield/3.0b2pre ID:2007112404
(In reply to comment #198)
> I get the following errors in my Error Console now. Not sure if it's a
> regression from this patch, but I haven't noticed them before:
> 
> Warning: Key event not available on GTK2: key="b" modifiers="accel,shift"
> Source File: chrome://browser/content/browser.xul
> Line: 0

According to this thread those warnings are not new: http://forums.mozillazine.org/viewtopic.php?t=370221

It's probably some internal XUL diagnostics messages, I doubt they are caused by my patch. I'll have a deeper look at it (I'm not an expert in XUL).
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.
(In reply to comment #200)
Thanks, Oleg.

Alt is used for non-Latin menu access key localizations in firefox 2.0, and so should not be forced to the Latin layout.

I recommend testing for isControl only unless there is a known need for isMeta.
I'm not sure that there is convenient way to implement such thing in nsNativeKeyBindings::KeyPress (it takes another event only with unicode character), I'm week in gtk*, but think that there enough routines to convert key into Latin character.
This function is the lost in analyzing the keyEvent. It calls gtk_bindings_activate(GTK_OBJECT(mNativeTarget),
                        keyCode, GdkModifierType(modifiers))
So, it may be much better to put hack code there.

Also I found that the difference between Latin and non-Latin keys only in result of gtk_bindings_activate (for Russian keys it returns false), so I think that it may be localization problem (as I found, in gtk all keys_bindings have to be localized and it's XUL-style).
If I have a time I will play with it.
I'm not sure that there is convenient way to implement such thing in nsNativeKeyBindings::KeyPress (it takes another event only with unicode character), I'm week in gtk*, but think that there enough routines to convert key into Latin character.
This function is the lost in analyzing the keyEvent. It calls gtk_bindings_activate(GTK_OBJECT(mNativeTarget),
                        keyCode, GdkModifierType(modifiers))
So, it may be much better to put hack code there.

Also I found that the difference between Latin and non-Latin keys only in result of gtk_bindings_activate (for Russian keys it returns false), so I think that it may be localization problem (as I found, in gtk all keys_bindings have to be localized and it's XUL-style).
If I have a time I will play with it.
Sorry, I've duplicated the message and can't remove it.
Hey, I've some interesting things about this bug (got them without patch):
1. Russian localization is wrong (it has mistakes in shortcuts localization)
<!ENTITY copyCmd.label "Copy (Here was the Russian word">
<!ENTITY copyCmd.key "C">
<!ENTITY copyCmd.accesskey "К (this is not the letter which is on the same key as English 'c'">

2.
I tried ctrl+k (it's the Russian 'k', placed to the 'R', not English). And I saw copied word in the klipper (KDE buffer manager). But I couldn't edit it. Also it was't cosed by routines that work with standart shortcuts.

(In reply to comment #205)
> Hey, I've some interesting things about this bug (got them without patch):
> 1. Russian localization is wrong (it has mistakes in shortcuts localization)
> <!ENTITY copyCmd.label "Copy (Here was the Russian word">
> <!ENTITY copyCmd.key "C">
> <!ENTITY copyCmd.accesskey "К (this is not the letter which is on the same key
> as English 'c'">

accesskey is the menu access key.  I assume "К" is part of the Russian translation of "Copy", which makes sense to me.

> 2.
> I tried ctrl+k (it's the Russian 'k', placed to the 'R', not English). And I
> saw copied word in the klipper (KDE buffer manager). But I couldn't edit it.
> Also it was't cosed by routines that work with standart shortcuts.
> 

If you open the "Edit" menu (sorry I don't know the russian translation)
then press "К" (on latin "R" but in Russian layout) then Copy should behave as expected.

Opening the "Edit" menu can be done with the mouse but, if you are using menu access keys you would use an Alt-<key> combination.  These Alt-<key> combinations used to be localized.  But, with the change in the patch here, they will now have to be Latin, because there is no way to get the Alt-<russian key>.
That is Bug 399939.

The commmandkey indicates the accelerator key to use with Ctrl.
(In reply to comment #206)
> (In reply to comment #205)

> 
> accesskey is the menu access key.  I assume "К" is part of the Russian
> translation of "Copy", which makes sense to me.
Yes, it is.

>Alt-<russian
> key>.
> That is Bug 399939.
> 
> The commmandkey indicates the accelerator key to use with Ctrl.

Sorry, didn't know. You're right 

The problem (in textItems (textEdits,forms) really is in gtk_bindings_activate).
First I thought it was a bug:
http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00003.html

But it's difficult to send GdkEventKey there (xpcom and other devil things). I will try (but insufficient time...) to remake it. This will fix any forms shortcuts. Something else should be for the text on the page (and also find, ctrl+b and so on). So, I see that this bug consist on 2 different (but similar) bugs.
   
It's (nsNativeKeyBindings::KeyPress) called from base class (wich is base for every Event Class in the hole application... There is no way to change the interface (change means break the whole EventSystem and then make new based on the old one). But there should be a way to change the events for the gtk part of code.
Next Friday/Saturday I will try (I wish I have a vocation now :) or the beginning of the term).
It fixes shortcuts for textEdits (forms). It doesn't use any char conversions.
The patched is maked against the code with the last applied patch (maybe the both fix the alt+menu shortcuts).
It's an example of the bug may be fully solved without char conversions ans causing new bugs (399939).
P.S. Sorry, I don't know what flags to choose (and if I should choose them).
Attachment #291019 - Flags: review?(reed)
Comment on attachment 291019 [details] [diff] [review]
Fixes the shortcuts of the textEdit (forms and etc). Maybe fixes Bug 399939

Please file a new bug for this issue. You should also create your patches from CVS to make sure you are up-to-date. Also, I'm not the reviewer you want. You should request review and superreview from roc.
Attachment #291019 - Attachment is obsolete: true
Attachment #291019 - Flags: review?(reed)
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?
Depends on: 406407
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


(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 :)
Depends on: 407604
Some of the shortcuts problems are caused by clipboard handling, see Bug 407604.
Flags: blocking1.8.1.9?
Blocks: fx3-l10n-he
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.
Blocks: Persian-Fx3.5
It Works! tested with FF v3.0b3 (us qwerty + greek qwerty layouts)

MANY THANKS to everyone involved!
Comment on attachment 290399 [details] [diff] [review]
look for latin key if modifier is down [rediffed for firefox 2.0]

It's very annoying. Everybody is tired from it
Attachment #290399 - Flags: superreview?(roc)
Attachment #290399 - Flags: review?(roc)
Attachment #290399 - Flags: approval1.8.1.13?
Attachment #290399 - Flags: approval1.8.1.13?
(In reply to comment #230)
See 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.
Attachment #307428 - Flags: superreview?(roc)
Attachment #307428 - Flags: review?(roc)
Attachment #290399 - Attachment is obsolete: true
Attachment #290399 - Flags: superreview?(roc)
Attachment #290399 - Flags: review?(roc)
Blocks: fx35-l10n-fa
No longer blocks: Persian-Fx3.5
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.
No longer blocks: fx35-l10n-fa
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.
Attachment #307428 - Flags: superreview?(roc)
Attachment #307428 - Flags: superreview+
Attachment #307428 - Flags: review?(roc)
Attachment #307428 - Flags: review+
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
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: