kubuntu-gr team mailing list archive

Thread
Date
[Bug 2561] Re: keyboard shortcuts when keyboard set to non-english language

To: kubuntu-gr@xxxxxxxxxxxxxxxxxxx
From: Bug Watch Updater <2561@xxxxxxxxxxxxxxxxxx>
Date: Thu, 14 Mar 2019 05:04:13 -0000
Reply-to: Bug 2561 <2561@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx
Launchpad has imported 252 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=69230.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2001-02-17T22:27:48+00:00 Hp-pobox wrote:

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. ;-)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/0

------------------------------------------------------------------------
On 2001-02-19T23:20:12+00:00 Akkana Peck wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/1

------------------------------------------------------------------------
On 2001-02-20T00:43:10+00:00 Hp-pobox wrote:

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.



  

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/2

------------------------------------------------------------------------
On 2001-04-11T17:55:32+00:00 alecf wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/3

------------------------------------------------------------------------
On 2001-04-11T18:31:19+00:00 Hp-pobox wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/4

------------------------------------------------------------------------
On 2001-04-18T21:49:03+00:00 alecf wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/5

------------------------------------------------------------------------
On 2001-07-23T23:27:17+00:00 Aaronlev wrote:

Reassigning alecf keyboard bugs.

UNIX keyboard stuff -> Akkana

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/6

------------------------------------------------------------------------
On 2002-02-26T13:04:30+00:00 Hp-pobox wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/7

------------------------------------------------------------------------
On 2004-12-08T00:55:54+00:00 Simos Xenitellis  wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/8

------------------------------------------------------------------------
On 2004-12-08T00:58:46+00:00 Simos Xenitellis  wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/9

------------------------------------------------------------------------
On 2004-12-08T01:06:13+00:00 Simos Xenitellis  wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/10

------------------------------------------------------------------------
On 2004-12-20T01:37:51+00:00 Simos Xenitellis  wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/11

------------------------------------------------------------------------
On 2005-08-12T22:24:42+00:00 Simos Xenitellis  wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/12

------------------------------------------------------------------------
On 2005-08-13T11:59:57+00:00 Shoshannah Forbes wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/13

------------------------------------------------------------------------
On 2005-12-30T13:12:56+00:00 Ilya-konstantinov+future wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/15

------------------------------------------------------------------------
On 2006-01-03T21:16:07+00:00 Eyalroz wrote:

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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/16

------------------------------------------------------------------------
On 2006-01-13T09:09:01+00:00 Eyalroz wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/17

------------------------------------------------------------------------
On 2006-01-22T10:31:28+00:00 Simos Xenitellis  wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/18

------------------------------------------------------------------------
On 2006-01-29T19:31:30+00:00 Sergey V. Udaltsov wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/19

------------------------------------------------------------------------
On 2006-06-23T19:50:22+00:00 Dmitry Agafonov wrote:

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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/29

------------------------------------------------------------------------
On 2006-07-24T10:29:39+00:00 Cernii wrote:

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.


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/30

------------------------------------------------------------------------
On 2006-07-31T19:25:51+00:00 Mozilla-s wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/31

------------------------------------------------------------------------
On 2006-09-13T10:30:10+00:00 Sergey Svishchev wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/32

------------------------------------------------------------------------
On 2006-09-26T19:57:52+00:00 admarginem wrote:

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 ;-)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/33

------------------------------------------------------------------------
On 2006-09-27T08:52:00+00:00 Paul Pogonyshev wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/34

------------------------------------------------------------------------
On 2006-09-29T23:33:58+00:00 Maysara wrote:

on FF2 rc1, still not working :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/35

------------------------------------------------------------------------
On 2006-10-16T21:31:27+00:00 Timeless-bemail wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/37

------------------------------------------------------------------------
On 2006-10-16T22:06:42+00:00 Eyalroz wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/38

------------------------------------------------------------------------
On 2006-10-16T22:32:21+00:00 Paul Pogonyshev wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/39

------------------------------------------------------------------------
On 2006-10-17T13:45:31+00:00 Timeless-bemail wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/41

------------------------------------------------------------------------
On 2006-10-17T13:58:31+00:00 Paul Pogonyshev wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/42

------------------------------------------------------------------------
On 2006-10-17T14:09:36+00:00 Avatar-b wrote:

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"?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/43

------------------------------------------------------------------------
On 2006-10-17T14:11:35+00:00 Eyalroz wrote:

(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.
 

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/44

------------------------------------------------------------------------
On 2006-10-17T14:19:15+00:00 Avatar-b wrote:

timeless: see comment #4 for what gtk does. Can you take it as
specification?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/45

------------------------------------------------------------------------
On 2006-10-17T15:11:10+00:00 Paul Pogonyshev wrote:

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?


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/46

------------------------------------------------------------------------
On 2006-10-17T16:19:29+00:00 Timeless-bemail wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/47

------------------------------------------------------------------------
On 2006-10-17T16:55:31+00:00 Eyalroz wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/48

------------------------------------------------------------------------
On 2006-10-17T16:55:59+00:00 Eyalroz wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/49

------------------------------------------------------------------------
On 2006-10-17T16:56:55+00:00 Ndemou-gmail wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/50

------------------------------------------------------------------------
On 2006-10-17T17:10:08+00:00 Tsahi-75 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/51

------------------------------------------------------------------------
On 2006-10-17T18:54:12+00:00 Smontagu wrote:

(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=|

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/52

------------------------------------------------------------------------
On 2006-10-17T19:06:31+00:00 Hp-pobox wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/53

------------------------------------------------------------------------
On 2006-10-17T21:30:22+00:00 Brade wrote:

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@xxxxxxxxxx -- 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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/54

------------------------------------------------------------------------
On 2006-10-17T21:51:10+00:00 Hp-pobox wrote:

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)


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/55

------------------------------------------------------------------------
On 2006-10-18T08:01:17+00:00 Ndemou-gmail wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/56

------------------------------------------------------------------------
On 2006-10-18T09:19:42+00:00 Paul Pogonyshev wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/57

------------------------------------------------------------------------
On 2006-10-18T11:10:20+00:00 Helge Hielscher wrote:

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, ...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/58

------------------------------------------------------------------------
On 2006-10-18T13:07:09+00:00 Sergey V. Udaltsov wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/59

------------------------------------------------------------------------
On 2006-10-26T21:13:53+00:00 Nir Misgav wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/60

------------------------------------------------------------------------
On 2006-10-27T09:30:29+00:00 Nir Misgav wrote:

^^^
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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/61

------------------------------------------------------------------------
On 2006-10-29T01:52:31+00:00 Amos Shapira wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/62

------------------------------------------------------------------------
On 2006-10-29T07:15:31+00:00 Eyalroz wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/63

------------------------------------------------------------------------
On 2006-12-10T00:02:58+00:00 Daniel Stone wrote:

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)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/64

------------------------------------------------------------------------
On 2006-12-27T10:12:19+00:00 Mozilla-bugs-2011-08 wrote:

@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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/65

------------------------------------------------------------------------
On 2006-12-27T16:53:52+00:00 Paul Pogonyshev wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/66

------------------------------------------------------------------------
On 2007-03-12T20:16:32+00:00 Muxec wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/67

------------------------------------------------------------------------
On 2007-03-13T01:23:21+00:00 Simos Xenitellis  wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/68

------------------------------------------------------------------------
On 2007-03-13T05:33:02+00:00 Helge Hielscher wrote:

(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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/69

------------------------------------------------------------------------
On 2007-03-13T13:54:49+00:00 Mozilla-bugs-2011-08 wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/70

------------------------------------------------------------------------
On 2007-03-13T14:29:08+00:00 Avatar-b wrote:

KDE Ctrl-shortcuts work for Russian. Please see my reply at
http://bugs.kde.org/show_bug.cgi?id=71147.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/71

------------------------------------------------------------------------
On 2007-03-24T16:12:08+00:00 Pier11 wrote:

Very annoying and long lasting bug. FIX IT PLEASE!!!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/72

------------------------------------------------------------------------
On 2007-03-24T19:54:29+00:00 3-alex-o wrote:

BTW, Epiphany isn't affected by this bug.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/73

------------------------------------------------------------------------
On 2007-03-30T15:36:35+00:00 Jen-evg wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/74

------------------------------------------------------------------------
On 2007-03-30T15:56:25+00:00 Mozilla-bugs-2011-08 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/75

------------------------------------------------------------------------
On 2007-04-12T17:58:17+00:00 Simos Xenitellis  wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/76

------------------------------------------------------------------------
On 2007-04-25T07:47:29+00:00 Dmitrii 'Mamut' Dimandt wrote:

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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/77

------------------------------------------------------------------------
On 2007-04-25T13:34:38+00:00 Mozilla-bugs-2011-08 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/78

------------------------------------------------------------------------
On 2007-05-10T21:18:20+00:00 Pier11 wrote:

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???

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/80

------------------------------------------------------------------------
On 2007-05-10T21:42:39+00:00 3-alex-o wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/81

------------------------------------------------------------------------
On 2007-05-10T23:03:48+00:00 Amos Shapira wrote:

(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).


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/82

------------------------------------------------------------------------
On 2007-05-11T05:57:20+00:00 Mozilla-bugs-2011-08 wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/83

------------------------------------------------------------------------
On 2007-06-02T12:27:14+00:00 Amnon Aaronsohn wrote:

Created attachment 267004
ignore keyboard group/level

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/84

------------------------------------------------------------------------
On 2007-06-03T05:51:26+00:00 Mozilla-s wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/85

------------------------------------------------------------------------
On 2007-06-03T08:53:18+00:00 Amnon Aaronsohn wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/86

------------------------------------------------------------------------
On 2007-07-14T16:48:33+00:00 Unghost-mozilla-russia wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/87

------------------------------------------------------------------------
On 2007-07-14T16:50:15+00:00 Unghost-mozilla-russia wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/88

------------------------------------------------------------------------
On 2007-08-21T14:35:57+00:00 ankostis wrote:

Any progress??

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/89

------------------------------------------------------------------------
On 2007-08-21T14:55:58+00:00 Dmitrii 'Mamut' Dimandt wrote:

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...


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/90

------------------------------------------------------------------------
On 2007-08-21T15:39:28+00:00 Simos Xenitellis  wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/91

------------------------------------------------------------------------
On 2007-08-22T06:32:10+00:00 Sergey Svishchev wrote:

Someone should mark bug 229284 and bug 340944 as dups of this one.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/92

------------------------------------------------------------------------
On 2007-08-22T09:49:13+00:00 Ndemou-gmail wrote:

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"

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/93

------------------------------------------------------------------------
On 2007-08-22T10:09:46+00:00 Egor-pelevin wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/94

------------------------------------------------------------------------
On 2007-08-22T10:42:00+00:00 ankostis wrote:

@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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/95

------------------------------------------------------------------------
On 2007-08-22T10:46:59+00:00 Ndemou-gmail wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/96

------------------------------------------------------------------------
On 2007-08-22T11:06:14+00:00 Egor-pelevin wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/97

------------------------------------------------------------------------
On 2007-08-22T11:14:12+00:00 Dmitrii 'Mamut' Dimandt wrote:

> 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/98

------------------------------------------------------------------------
On 2007-08-22T12:04:23+00:00 Dmitrii 'Mamut' Dimandt wrote:

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 :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/99

------------------------------------------------------------------------
On 2007-08-22T12:18:37+00:00 Egor-pelevin wrote:

dev3 = ego = me :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/100

------------------------------------------------------------------------
On 2007-08-22T15:34:15+00:00 Ndemou-gmail wrote:

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 :).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/101

------------------------------------------------------------------------
On 2007-08-22T16:26:16+00:00 Unghost-mozilla-russia wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/102

------------------------------------------------------------------------
On 2007-08-22T16:27:17+00:00 Unghost-mozilla-russia wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/103

------------------------------------------------------------------------
On 2007-08-22T16:37:38+00:00 Sergey Svishchev wrote:

bug 124123 also looks similar.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/104

------------------------------------------------------------------------
On 2007-08-22T16:42:43+00:00 Sergey Svishchev wrote:

...and bug 177508, too.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/105

------------------------------------------------------------------------
On 2007-08-22T16:49:16+00:00 Unghost-mozilla-russia wrote:

(In reply to comment #91)
> bug 124123 also looks similar.
> 
Bug 124123 reported on Windows 2000. I guess it's different issue.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/106

------------------------------------------------------------------------
On 2007-08-23T06:07:01+00:00 Dmitrii 'Mamut' Dimandt wrote:

(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 :)


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/107

------------------------------------------------------------------------
On 2007-08-23T12:53:56+00:00 Ndemou-gmail wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/108

------------------------------------------------------------------------
On 2007-08-23T13:06:59+00:00 Sergey V. Udaltsov wrote:

> 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_".

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/109

------------------------------------------------------------------------
On 2007-08-23T13:16:43+00:00 Mozilla-bugs-2011-08 wrote:

@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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/110

------------------------------------------------------------------------
On 2007-08-23T13:27:07+00:00 ankostis wrote:

@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.


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/111

------------------------------------------------------------------------
On 2007-08-23T13:32:49+00:00 Sergey V. Udaltsov wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/112

------------------------------------------------------------------------
On 2007-08-23T13:56:46+00:00 Dmitrii 'Mamut' Dimandt wrote:

(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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/113

------------------------------------------------------------------------
On 2007-08-23T14:03:37+00:00 Sergey V. Udaltsov wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/114

------------------------------------------------------------------------
On 2007-08-23T15:44:22+00:00 Ndemou-gmail wrote:

@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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/115

------------------------------------------------------------------------
On 2007-08-23T16:10:09+00:00 Ndemou-gmail wrote:

@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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/116

------------------------------------------------------------------------
On 2007-08-23T16:30:46+00:00 Nickolay Ponomarev wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/117

------------------------------------------------------------------------
On 2007-08-23T18:16:46+00:00 Mozilla-bugs-2011-08 wrote:

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!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/118

------------------------------------------------------------------------
On 2007-08-23T18:52:54+00:00 Simos Xenitellis  wrote:

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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/119

------------------------------------------------------------------------
On 2007-08-27T08:38:29+00:00 Ndemou-gmail wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/120

------------------------------------------------------------------------
On 2007-08-27T22:59:44+00:00 Mozilla-bugs-2011-08 wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/121

------------------------------------------------------------------------
On 2007-08-29T21:40:19+00:00 Zeniko wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/122

------------------------------------------------------------------------
On 2007-09-05T11:03:07+00:00 Jo-hermans wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/123

------------------------------------------------------------------------
On 2007-09-10T08:27:04+00:00 Smontagu wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/124

------------------------------------------------------------------------
On 2007-09-10T09:34:17+00:00 Ofir Klinger wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/125

------------------------------------------------------------------------
On 2007-09-10T10:26:30+00:00 Mozilla-bugs-2011-08 wrote:

@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!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/126

------------------------------------------------------------------------
On 2007-09-10T10:40:09+00:00 Ofir Klinger wrote:

(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!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/127

------------------------------------------------------------------------
On 2007-09-10T10:50:10+00:00 Dmitrii 'Mamut' Dimandt wrote:

> 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/128

------------------------------------------------------------------------
On 2007-09-11T22:08:59+00:00 Shai Berger wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/129

------------------------------------------------------------------------
On 2007-09-17T07:24:28+00:00 ankostis wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/130

------------------------------------------------------------------------
On 2007-09-17T07:32:29+00:00 Shai-t wrote:

(In reply to comment #117)
> (In reply to comment #116)
> > you can switch layouts


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/131

------------------------------------------------------------------------
On 2007-09-17T07:41:34+00:00 Dmitrii 'Mamut' Dimandt wrote:

> 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*

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/132

------------------------------------------------------------------------
On 2007-09-17T07:58:00+00:00 Ofir Klinger wrote:

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.*"?


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/133

------------------------------------------------------------------------
On 2007-09-17T08:03:22+00:00 Shai-t wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/134

------------------------------------------------------------------------
On 2007-09-17T08:49:44+00:00 Nicolas-mailhot-laposte wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/135

------------------------------------------------------------------------
On 2007-09-17T08:56:49+00:00 Dmitrii 'Mamut' Dimandt wrote:

>  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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/136

------------------------------------------------------------------------
On 2007-09-17T09:04:28+00:00 Ofir Klinger wrote:

(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).


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/137

------------------------------------------------------------------------
On 2007-09-17T09:38:50+00:00 Dmitrii 'Mamut' Dimandt wrote:

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 :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/138

------------------------------------------------------------------------
On 2007-09-17T09:46:29+00:00 Dtownsend wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/139

------------------------------------------------------------------------
On 2007-09-19T06:23:50+00:00 M-thommy wrote:

Created attachment 281426
bugspam, ignore me

debug

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/140

------------------------------------------------------------------------
On 2007-09-19T06:36:20+00:00 M-thommy wrote:

Created attachment 281427
bugspam, ignore me

debug

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/141

------------------------------------------------------------------------
On 2007-09-27T18:17:05+00:00 Dveditz wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/142

------------------------------------------------------------------------
On 2007-09-27T18:42:16+00:00 Shai Berger wrote:

(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?


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/143

------------------------------------------------------------------------
On 2007-09-27T22:54:34+00:00 Dveditz wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/144

------------------------------------------------------------------------
On 2007-09-28T00:53:07+00:00 Shai Berger wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/145

------------------------------------------------------------------------
On 2007-09-28T01:43:30+00:00 Amos Shapira wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/146

------------------------------------------------------------------------
On 2007-09-28T07:46:38+00:00 Nicolas-mailhot-laposte wrote:

(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?


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/147

------------------------------------------------------------------------
On 2007-09-28T09:45:04+00:00 Dmitrii 'Mamut' Dimandt wrote:

> 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).


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/148

------------------------------------------------------------------------
On 2007-09-28T15:50:10+00:00 Mozilla-bugs-2011-08 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/149

------------------------------------------------------------------------
On 2007-09-28T16:03:48+00:00 Marcoos+bmo wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/150

------------------------------------------------------------------------
On 2007-09-28T19:10:14+00:00 Mozilla-bugs-2011-08 wrote:

Good to know, thanks.

In that case: Aaron! We need you!!! Please pop in and let us know what's
going on! Thanks!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/151

------------------------------------------------------------------------
On 2007-09-29T15:46:48+00:00 Gervase Markham wrote:

The content of attachment 281426 has been deleted by
    Gervase Markham <gerv@xxxxxxxxxxx>
who provided the following reason:

Porn

The token used to delete this attachment was generated at 2007-09-29
08:46:38 PDT.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/152

------------------------------------------------------------------------
On 2007-09-29T15:47:01+00:00 Gervase Markham wrote:

The content of attachment 281427 has been deleted by
    Gervase Markham <gerv@xxxxxxxxxxx>
who provided the following reason:

Porn

The token used to delete this attachment was generated at 2007-09-29
08:46:55 PDT.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/153

------------------------------------------------------------------------
On 2007-09-30T04:05:23+00:00 Dveditz wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/154

------------------------------------------------------------------------
On 2007-09-30T12:09:31+00:00 Mozilla-bugs-2011-08 wrote:

Stumbled. Quite a few people should see the bug now.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/155

------------------------------------------------------------------------
On 2007-09-30T21:05:18+00:00 Roc-ocallahan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/156

------------------------------------------------------------------------
On 2007-10-01T13:21:18+00:00 Ndemou-gmail wrote:

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)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/157

------------------------------------------------------------------------
On 2007-10-10T08:52:03+00:00 Gervase Markham wrote:

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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/158

------------------------------------------------------------------------
On 2007-10-11T10:43:02+00:00 DarkOne wrote:

Created attachment 284450
look for latin key if modifier is down

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/159

------------------------------------------------------------------------
On 2007-10-11T12:40:49+00:00 Ndemou-gmail wrote:

Thanks Oleg, your description of the algorithm seems OK - how can we
test it in real life?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/160

------------------------------------------------------------------------
On 2007-10-11T13:04:02+00:00 Bug-dmca wrote:

Created attachment 284457
review roc@xxxxxxxxxxxxx

I create small patch. I hope many people test it and write about my
errors. I need review from roc@xxxxxxxxxxxxx. I works with firefox
2.0.0.7. I test it with 2 languages (eng+rus) and only with rus.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/161

------------------------------------------------------------------------
On 2007-10-11T13:10:35+00:00 Ofir Klinger wrote:

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?)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/162

------------------------------------------------------------------------
On 2007-10-11T13:38:29+00:00 Bug-dmca wrote:

Oh, I see that my patch is similar to amnonaar@xxxxxxxxx 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/163

------------------------------------------------------------------------
On 2007-10-11T13:43:15+00:00 Sergey V. Udaltsov wrote:

> if english language always on group 0, level 0,

Wrong assumption, generally speaking. Configuration 'ru,us' is perfectly
valid

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/164

------------------------------------------------------------------------
On 2007-10-11T13:51:07+00:00 Nickolay Ponomarev wrote:

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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/165

------------------------------------------------------------------------
On 2007-10-11T14:07:25+00:00 Bug-dmca wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/166

------------------------------------------------------------------------
On 2007-10-11T14:10:19+00:00 Sergey V. Udaltsov wrote:

It means your patch does not require latin characters to be in group 0;)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/167

------------------------------------------------------------------------
On 2007-10-11T14:14:50+00:00 Bug-dmca wrote:

(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 :) )

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/168

------------------------------------------------------------------------
On 2007-10-11T22:26:50+00:00 Roc-ocallahan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/169

------------------------------------------------------------------------
On 2007-10-11T22:42:55+00:00 Nicolas-mailhot-laposte wrote:

(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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/170

------------------------------------------------------------------------
On 2007-10-11T22:56:55+00:00 Roc-ocallahan wrote:

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".

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/171

------------------------------------------------------------------------
On 2007-10-12T04:03:16+00:00 Amos Shapira wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/172

------------------------------------------------------------------------
On 2007-10-12T05:43:01+00:00 Mozilla-bugs-2011-08 wrote:

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!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/173

------------------------------------------------------------------------
On 2007-10-12T06:17:53+00:00 Karlt wrote:

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...)


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/174

------------------------------------------------------------------------
On 2007-10-12T06:21:56+00:00 Nicolas-mailhot-laposte wrote:

(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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/175

------------------------------------------------------------------------
On 2007-10-12T06:45:18+00:00 Shai Berger wrote:

(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.



Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/176

------------------------------------------------------------------------
On 2007-10-12T06:53:59+00:00 Mozilla-bugs-2011-08 wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/177

------------------------------------------------------------------------
On 2007-10-12T06:59:45+00:00 Amos Shapira wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/178

------------------------------------------------------------------------
On 2007-10-12T07:17:24+00:00 Mozilla-bugs-2011-08 wrote:

> 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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/179

------------------------------------------------------------------------
On 2007-10-12T07:36:52+00:00 Ndemou-gmail wrote:

(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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/180

------------------------------------------------------------------------
On 2007-10-12T08:21:54+00:00 Nicolas-mailhot-laposte wrote:

(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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/181

------------------------------------------------------------------------
On 2007-10-12T08:32:19+00:00 Nicolas-mailhot-laposte wrote:

(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)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/182

------------------------------------------------------------------------
On 2007-10-12T10:28:15+00:00 DarkOne wrote:

Created attachment 284606
look for latin key if modifier is down [try2]

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/183

------------------------------------------------------------------------
On 2007-10-12T21:21:19+00:00 Simos Xenitellis  wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/184

------------------------------------------------------------------------
On 2007-10-14T04:49:20+00:00 Smontagu wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/185

------------------------------------------------------------------------
On 2007-10-16T02:29:44+00:00 Karlt wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/186

------------------------------------------------------------------------
On 2007-10-16T02:37:13+00:00 Karlt wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/187

------------------------------------------------------------------------
On 2007-10-16T04:29:52+00:00 Karlt wrote:

_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.)


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/188

------------------------------------------------------------------------
On 2007-10-16T06:16:27+00:00 Nicolas-mailhot-laposte wrote:

(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


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/189

------------------------------------------------------------------------
On 2007-11-20T14:50:25+00:00 Paul Pogonyshev wrote:

Just wonderful, tested 3.0 beta 1 or how is it named -- not working.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/190

------------------------------------------------------------------------
On 2007-11-20T14:54:59+00:00 Ofir Klinger wrote:

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!)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/191

------------------------------------------------------------------------
On 2007-11-20T14:58:17+00:00 Ted-f wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/192

------------------------------------------------------------------------
On 2007-11-20T15:33:18+00:00 Mozilla-bugs-2011-08 wrote:

(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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/193

------------------------------------------------------------------------
On 2007-11-20T15:43:35+00:00 Nicolas-mailhot-laposte wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/194

------------------------------------------------------------------------
On 2007-11-21T14:41:04+00:00 Paul Pogonyshev wrote:

P5 --- least important, milestone --- future (distant, I guess).  At
least 2 patches, both unreviewed.  Open for almost 7 years, almost 200
comments.  I really fucking 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?


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/195

------------------------------------------------------------------------
On 2007-11-21T19:53:43+00:00 Tomer-moz-bugs wrote:

(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. ;-)


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/196

------------------------------------------------------------------------
On 2007-11-21T21:40:02+00:00 Roc-ocallahan wrote:

I think we could take Oleg's patch if someone addresses Karl's comment
#175 about checking for the same level.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/197

------------------------------------------------------------------------
On 2007-11-21T22:11:08+00:00 Mozilla-bugs-2011-08 wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/198

------------------------------------------------------------------------
On 2007-11-21T22:21:42+00:00 Roc-ocallahan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/199

------------------------------------------------------------------------
On 2007-11-22T09:37:38+00:00 Mozilla-bugs-2011-08 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/200

------------------------------------------------------------------------
On 2007-11-22T19:08:00+00:00 DarkOne wrote:

Created attachment 289837
look for latin key if modifier is down [try3]

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/201

------------------------------------------------------------------------
On 2007-11-22T19:59:20+00:00 Roc-ocallahan wrote:

Comment on attachment 289837
look for latin key if modifier is down [try3]

great!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/202

------------------------------------------------------------------------
On 2007-11-23T01:01:53+00:00 Mozilla-bugs-2011-08 wrote:

Thanks, Oleg!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/203

------------------------------------------------------------------------
On 2007-11-23T01:39:22+00:00 Reed Loden wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/204

------------------------------------------------------------------------
On 2007-11-23T11:46:17+00:00 Dmitrii 'Mamut' Dimandt wrote:

So, does it mean now that all is needed for the patch is to make it into
the trunk?

Yay!!!! :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/205

------------------------------------------------------------------------
On 2007-11-23T15:12:27+00:00 Reed Loden wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/206

------------------------------------------------------------------------
On 2007-11-23T15:27:19+00:00 Dmitrii 'Mamut' Dimandt wrote:

Hurrah!

Yay!

You guys are the best! :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/207

------------------------------------------------------------------------
On 2007-11-24T15:41:48+00:00 Kairo-kairo wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/208

------------------------------------------------------------------------
On 2007-11-24T16:01:08+00:00 Ofir Klinger wrote:

Great Job!

I'm very glad that this 6-years bug was solved. Finally!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/209

------------------------------------------------------------------------
On 2007-11-24T16:07:30+00:00 Zzfi-live wrote:

Backport plz. to  rv:1.8

I am waiting this fix five year!!!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/210

------------------------------------------------------------------------
On 2007-11-24T19:01:42+00:00 Reed Loden wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/211

------------------------------------------------------------------------
On 2007-11-24T22:41:46+00:00 DarkOne wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/212

------------------------------------------------------------------------
On 2007-11-27T16:20:25+00:00 DarkOne wrote:

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

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/213

------------------------------------------------------------------------
On 2007-11-27T19:00:47+00:00 Karlt wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/214

------------------------------------------------------------------------
On 2007-11-28T12:44:44+00:00 Ivanov-q wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/215

------------------------------------------------------------------------
On 2007-11-28T14:43:48+00:00 Ivanov-q wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/216

------------------------------------------------------------------------
On 2007-11-28T14:45:29+00:00 Ivanov-q wrote:

Sorry, I've duplicated the message and can't remove it.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/217

------------------------------------------------------------------------
On 2007-11-30T20:59:58+00:00 Ivanov-q wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/218

------------------------------------------------------------------------
On 2007-11-30T21:20:13+00:00 Karlt wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/219

------------------------------------------------------------------------
On 2007-11-30T23:54:02+00:00 Ivanov-q wrote:

(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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/220

------------------------------------------------------------------------
On 2007-12-01T20:59:49+00:00 Ivanov-q wrote:

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.
   

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/221

------------------------------------------------------------------------
On 2007-12-01T21:30:12+00:00 Ivanov-q wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/222

------------------------------------------------------------------------
On 2007-12-01T23:49:43+00:00 Ivanov-q wrote:

Created attachment 291019
Fixes the shortcuts of the textEdit (forms and etc). Maybe fixes Bug 399939

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/223

------------------------------------------------------------------------
On 2007-12-02T00:24:51+00:00 Reed Loden wrote:

Comment on attachment 291019
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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/224

------------------------------------------------------------------------
On 2007-12-02T08:25:38+00:00 Ivanov-q wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/225

------------------------------------------------------------------------
On 2007-12-02T08:45:11+00:00 Jwalden-m wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/226

------------------------------------------------------------------------
On 2007-12-02T08:59:14+00:00 Ivanov-q wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/227

------------------------------------------------------------------------
On 2007-12-02T09:12:42+00:00 Jwalden-m wrote:

(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.  :-) )

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/228

------------------------------------------------------------------------
On 2007-12-02T09:18:24+00:00 Ivanov-q wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/229

------------------------------------------------------------------------
On 2007-12-02T09:24:13+00:00 Amos Shapira wrote:

(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?


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/230

------------------------------------------------------------------------
On 2007-12-02T10:30:46+00:00 Ivanov-q wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/231

------------------------------------------------------------------------
On 2007-12-03T20:02:35+00:00 Zzfi-live wrote:

(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


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/232

------------------------------------------------------------------------
On 2007-12-07T16:43:48+00:00 Jo-hermans wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/233

------------------------------------------------------------------------
On 2007-12-07T16:44:08+00:00 Jo-hermans wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/234

------------------------------------------------------------------------
On 2007-12-08T04:47:58+00:00 Jwalden-m wrote:

(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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/235

------------------------------------------------------------------------
On 2007-12-08T10:48:34+00:00 Ivanov-q wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/236

------------------------------------------------------------------------
On 2007-12-09T20:09:36+00:00 Ivanov-q wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/237

------------------------------------------------------------------------
On 2008-02-13T01:39:35+00:00 Jruderman wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/238

------------------------------------------------------------------------
On 2008-02-13T12:27:30+00:00 Dmitrii 'Mamut' Dimandt wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/239

------------------------------------------------------------------------
On 2008-02-13T14:30:05+00:00 Ehsan-mozilla wrote:

It will affect Firefox 3.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/240

------------------------------------------------------------------------
On 2008-02-13T22:12:21+00:00 Simos Xenitellis  wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/241

------------------------------------------------------------------------
On 2008-02-15T12:19:55+00:00 Ndemou-gmail wrote:

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

MANY THANKS to everyone involved!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/242

------------------------------------------------------------------------
On 2008-03-04T18:58:34+00:00 Ivanov-q wrote:

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

It's very annoying. Everybody is tired from it

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/243

------------------------------------------------------------------------
On 2008-03-04T21:39:40+00:00 Karlt wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/244

------------------------------------------------------------------------
On 2008-03-05T09:24:49+00:00 Ivanov-q wrote:

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

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/245

------------------------------------------------------------------------
On 2008-04-22T19:31:19+00:00 Eyalroz wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/246

------------------------------------------------------------------------
On 2008-04-22T19:41:53+00:00 Unghost-mozilla-russia wrote:

(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


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/247

------------------------------------------------------------------------
On 2008-04-22T21:34:44+00:00 Karlt wrote:

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

Bug 429970.  No check-in yet.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/248

------------------------------------------------------------------------
On 2008-06-12T01:02:58+00:00 Unghost-mozilla-russia wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/250

------------------------------------------------------------------------
On 2008-06-16T22:08:17+00:00 Shai Berger wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/251

------------------------------------------------------------------------
On 2008-06-16T22:38:48+00:00 Shai Berger wrote:

... 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.


Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/252

------------------------------------------------------------------------
On 2008-06-17T04:47:44+00:00 Smontagu wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/253

------------------------------------------------------------------------
On 2008-06-17T05:24:43+00:00 Karlt wrote:

(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.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/254

------------------------------------------------------------------------
On 2008-06-17T05:49:25+00:00 Haggai Eran wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/255

------------------------------------------------------------------------
On 2008-06-17T06:33:52+00:00 Ndemou-gmail wrote:

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) 


Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/256

------------------------------------------------------------------------
On 2008-06-17T10:24:32+00:00 Mozilla-bugs-2011-08 wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/257

------------------------------------------------------------------------
On 2008-06-17T10:25:17+00:00 Mozilla-bugs-2011-08 wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/258

------------------------------------------------------------------------
On 2008-06-17T16:41:44+00:00 Haggai Eran wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/259

------------------------------------------------------------------------
On 2008-06-17T16:46:02+00:00 Mozilla-bugs-2011-08 wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/260

------------------------------------------------------------------------
On 2008-06-17T20:02:17+00:00 Smontagu wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/261

------------------------------------------------------------------------
On 2008-06-18T09:48:35+00:00 Mozilla-bugs-2011-08 wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/262

------------------------------------------------------------------------
On 2008-08-27T10:21:08+00:00 Elez-d wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/263

------------------------------------------------------------------------
On 2008-08-27T11:16:08+00:00 Mozilla-bugs-2011-08 wrote:

@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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/264

------------------------------------------------------------------------
On 2017-04-03T01:02:10+00:00 Albert-3 wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2561/comments/265


** Bug watch added: Mozilla Bugzilla #88380
   https://bugzilla.mozilla.org/show_bug.cgi?id=88380

** Bug watch added: Mozilla Bugzilla #50255
   https://bugzilla.mozilla.org/show_bug.cgi?id=50255

** Bug watch added: Mozilla Bugzilla #164793
   https://bugzilla.mozilla.org/show_bug.cgi?id=164793

** Bug watch added: Mozilla Bugzilla #98376
   https://bugzilla.mozilla.org/show_bug.cgi?id=98376

** Bug watch added: Mozilla Bugzilla #218155
   https://bugzilla.mozilla.org/show_bug.cgi?id=218155

** Bug watch added: Mozilla Bugzilla #214412
   https://bugzilla.mozilla.org/show_bug.cgi?id=214412

** Bug watch added: OpenOffice.org Issue Tracker #39307
   http://qa.openoffice.org/issues/show_bug.cgi?id=39307

** Bug watch added: Mozilla Bugzilla #177508
   https://bugzilla.mozilla.org/show_bug.cgi?id=177508

** Bug watch added: KDE Bug Tracking System #71147
   https://bugs.kde.org/show_bug.cgi?id=71147

** Bug watch added: Novell/SUSE Bugzilla #204402
   https://bugzilla.novell.com/show_bug.cgi?id=204402

** Bug watch added: OpenOffice.org Issue Tracker #42122
   http://qa.openoffice.org/issues/show_bug.cgi?id=42122

** Bug watch added: GNOME Bug Tracker #162726
   https://gitlab.gnome.org/162726

** Bug watch added: OpenOffice.org Issue Tracker #57297
   http://qa.openoffice.org/issues/show_bug.cgi?id=57297

** Bug watch added: Mozilla Bugzilla #394997
   https://bugzilla.mozilla.org/show_bug.cgi?id=394997

** Bug watch added: Mozilla Bugzilla #452393
   https://bugzilla.mozilla.org/show_bug.cgi?id=452393

-- 
You received this bug notification because you are a member of Ubuntu
Greece, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2561

Title:
  keyboard shortcuts when keyboard set to non-english language

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/2561/+subscriptions