124123 - shortcuts without Ctrl/Alt do not work with cyrillic locale

Status: NEW

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

Description

[Victor Kazmirenko]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020406

While reading mail or news some shortcuts, namely "n" - next unread, "t"  - next
unread thread do not work if keyboard input locale switched to Russian or
Ukrainian. In a wishlist newsgroup it was said that shortcuts work with German
locale. It is true. But they do not work with cyrillic.

Reproducible: Always
Steps to Reproduce:
1.Open mail folder (checked with POP) or newsgroup with unread messages
2.Swith keyboard to Russian or Ukrainian
3.Press "n" or "t" key

Actual Results:  Nothing happens

Expected Results:  Next unread message/thread should be loaded (it was so
convenient in all Communicators)

Comment 1

[nhottanscp]

cc to putterman, do you khow where the short cut 'n' is implemented?

Comment 2

[marina]

yes, i can confirm that when the keyboard is switched to cyrrilic, greek or
japanese input the shortcuts do not work ( i was able to use them with czech,
polish, french, german, portugese)

Comment 3

[ji]

BTW, it's working on linux when keyboard switched to Russian.

Comment 4

[ji]

On W2K, when keyboard is switched to Japanese, shortcut works when it's in
English input mode, but not working when the input mode changed to Japanese by
pressing alt ~

Comment 5

[scottputterman]

cc'ing Sean.  Could you point Naoki to the code for this?

Comment 6

[Sean Su]

for 'n':
the implementation in xul is here:
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindowOverlay.xul#285

the localization implementation is here:
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/locale/en-US/messenger.dtd#308

for 't':
the implementation in xul is here:
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindowOverlay.xul#288

the localization implementation is here:
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/locale/en-US/messenger.dtd#314

Comment 7

[nhottanscp]

I think this is a generic issue of XUL key handling.
The current way is to specify a character code like 'f' not a key code. 
http://www.mozilla.org/xpfe/xulref/keys.html

So it only works if the user really inputs 'f', may not work even if pressing
the key labeled as 'f' depends on the keyboard locale.

Comment 8

[Victor Kazmirenko]

So, as I understand, it is an issue of the way which keyboard input is
interpreted. As I understand this is not bug in common sense but peculiarity of
program realisation that may take a lot of time to improve. could anybody
suggest is it possible to fix? 

Comment 9

[nhottanscp]

One way is to use 'keycode' instead of 'key', but 'keycode' seems to be only for
those special keys like 'VK_HOME'.
Other way is let localization to take care since the actual character is
localizable as it is defined in .dtd file.

Comment 10

[ji]

QA contact to marina. 

Comment 11

[nhottanscp]

Change component and reassign to hyatt. I think this is a generic XUL issue.

Can 'keycode' be used for a key like 'f' or 'n'?
If 'keycode' can be used instead of 'key' then we may change the mail code.
If not then I am not sure we should change to allow more keys for 'keycode', or
design UI to avoid those short cuts.

Comment 12

[nhottanscp]

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

Comment 13

[nhottanscp]

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

Comment 14

[nhottanscp]

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

Comment 15

[av (gone)]

Is anybody looking at this? There is no activity since February. Should we look
for another component/owner?

Comment 16

[Victor Kazmirenko]

It's a pitty but really there is no visible activity here. As suggested in
comment #11 resolving the problem may take considerable programming efforts,
related to the core. And as releases appear, the far we become from solution...
I afraid that described bug will have only workarround like 'Use latin locales
and do not compline'. Could anybody tell something, whether this bug considered
or investigated or maybe it is already dead.

Comment 17

[Damjan Georgievski]

Works in Firefox 3.0 .. Finally!!!

Comment 18

[Eugene Savitsky]

Dunno where it works but in Tb 3.0a1pre (2008050503) on WinXP it does not... The bug is set against Core, no mail functionality in FF. So where suppose this to work?

Comment 19

[Victor Kazmirenko]

(In reply to comment #18)
> Dunno where it works but in Tb 3.0a1pre (2008050503) on WinXP it does not...
> The bug is set against Core, no mail functionality in FF. So where suppose this
> to work?

Totally agree, although this issue could be related to FF as well, the original problem now belongs to TB. Sure, still does not work...

Comment 20

[Tim Babych]

n/p issue in in non-English keyboard layout is present in Thunderbird 3.1
also, "/" key for evoking quicksearch in Firefox 4.0b7pre also works only for English locale.

Comment 22

[klonos]

...coming from bug 579775. It also involves the following keys:

'm' for toggling Mark as Read/Unread
'j'/shift + 'j' for toggling Junk/Not Junk

but it DOES work for shortcuts that use CTRL + key, like:

CTRL + c/x/v for copy/cut/paste (in the editor and in text fields)
CTRL + b/u/i for bold/underlined/italics (in the editor)

I too think that instead of detecting which letter was typed and letting each locale handle things we should instead detect keystrokes by keycode somehow. This would make it global (...as in locale-independent I mean).

PS: + adding my vote on this one. Also, I know that by definition this is categorized as 'normal' (NO major loss of functionality), but I do feel that it should be upgraded in order to gain some attention. It is not even assigned to someone! I understand that new and shiny features will 'keep us in the game', but still this is a longstanding annoyance for all multilingual users that should be fixed before we move on. My experience has shown that ignoring issues ends up in them coming back to byte us in the long run.

Comment 23

[klonos]

...can we get some attention here please???