177508 - [ShortcutKey] Shortcut keys do not work without modifiers if non-Latain keyboard layout is active

Status: NEW

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

Description

[Eugene Savitsky]

1. set your keyboard to russain
2. ALT-D does not work (for selecting URL bar). 

CTRL-L instead works with both - latin or cyrillic keyboard selected.

moz 2002102808 (does not worked from beginning)

Comment 1

[Wesha]

Confirmed 2002102908/NT4. If active keyboard layout is Russian, Alt-D doesn't
work. I would suggest dropping the severity some though, since Ctrl-L is not
affected.

Comment 2

[Simon Montagu :smontagu]

Adjusting summary. Hebrew and Arabic keyboards have the same problem, and I
expect that many others do also.

Comment 3

[Eugene Savitsky]

Nominating for nsbeta1. 

Ie users are used to this combination and for many of them (I suppose all
non-latin) this will sometimes works, sometimes does not. It may feel that the
software is not good for them.

Tnx.

Comment 4

[Frank Tang]

ALt-D on window xp ? why should that select the url bar? which specification
said it should ?

Comment 5

[Samir Gehani]

i18n triage team: nsbeta1-

Comment 6

[Eugene Savitsky]

Is this related to the behavior that I canot mark the message in 3-pane window
as read/unread when using russian keyboard layout? 

Should I open a new bug for it?

Comment 7

[Simon Montagu :smontagu]

Yes, that is clearly the same issue. Changing summary.

Does that make any difference to the nsbeta1- ? The bug is not that a specific
shortcut doesn't work, but that all ALT-key shortcuts that work with the English
keyboard layout don't work if another language is selected.

Comment 8

[Eugene Savitsky]

Simon, in message pane the "M" does not works, without any modifier.

Comment 9

[Simon Montagu :smontagu]

Ah, good point. Expecting unmodified keys to retain their interpretation in
other keyboard mappings is raising the bar a bit, but is worth considering, I
suppose.

Comment 10

[Simon Montagu :smontagu]

This seems to be WORKSFORME in current trunk on Windows XP. Can anyone confirm
on other platforms?

Comment 11

[Simon Montagu :smontagu]

ere, do you think that either bug 197474 or the extra checkin you mention in bug
178110 comment 26 could have fixed this bug?

Comment 12

[Ere Maijala (slow)]

Yes, they could have. Those were quite extensive changes.

Comment 13

[Simon Montagu :smontagu]

The problem is that now alt access keys don't work for the menus of localized
versions with other input locales (seen in Hebrew firefox on the trunk)

Comment 14

[Simon Montagu :smontagu]

(In reply to comment #13)
> The problem is that now alt access keys don't work for the menus of localized
> versions with other input locales (seen in Hebrew firefox on the trunk)

This has been filed as bug 285161

Comment 15

[Behnam Esfahbod [:zwnj]]

For a localized desktop, any shortcut (Ctrl+KEY, Ctrl+Shift+KEY, etc) and
accelerator (Alt+KEY) should use desktop's default keyboard layout, not the
current selected;  e.i. for a Persian/Iranian desktop with the Iranian keyboard
layout as default and English layout as the second, Mozilla should open the file
menu with Alt+PEH ("File" -> "parvandeh") and the open file dialog with Ctrl+BEH
("Open" -> "baaz-kardan"), even if english layout is active.

Just note that translators should not localize all the shortcuts.  There are two
types of shortcuts:
1.  Shortcut's KEY is a letter of the FUNCTION, so it should (may?) be changed
to a letter of translated text.  (as "O" in "Open")
2.  Shortcut's KEY selected from it's position on the keyboard and should (may?)
not be changed, (as "Z" for "Undo") and just use the localized letter of the KEY
for that.

Comment 16

[Behnam Esfahbod [:zwnj]]

Ben asked to not change shortcuts of searchFocus.  I couldn't find him on
bugzilla, so I'll forward this bugmail for him to be informed about this bug.

His note on locale/browser/browser.dtd:
# Comment duplicated from browser-sets.inc:
#
# Search Command Key Logic works like this:
#
# Unix: Ctrl+J (0.8, 0.9 support)
# Ctrl+K (cross platform binding)
# Mac:  Ctrl+K (cross platform binding)
# Win:  Ctrl+K (cross platform binding)
# Ctrl+E (IE compat)
#
# We support Ctrl+K on all platforms now and advertise it in the menu since it is
# our standard - it is a "safe" choice since it is near no harmful keys like "W" as
# "E" is. People mourning the loss of Ctrl+K for emacs compat can switch their GTK
# system setting to use emacs emulation, and we should respect it. Focus-Search-Box
# is a fundamental keybinding and we are maintaining a XP binding so that it is easy
# for people to switch to Linux.
#
# Do *not* tamper with these values without talking to [e-mail]


We're going to make a standard on freedesktop.org for Persian Desktop's
shorcuts, as in Persian GNOME and Persian Mozilla.  AFAIK, fd.o has some for
Latin-based desktops.

Comment 17

[Behnam Esfahbod [:zwnj]]

Bug 69230 -- Accelerators should not be affected by keyboard group/level (DUP?)

Comment 18

[Simos Xenitellis]

(In reply to comment #17)
> Bug 69230 -- Accelerators should not be affected by keyboard group/level (DUP?)

Indeed, do read Bug 69230

It has reference to a discussion in the GTK+ mailing list about how GTK+ manages
quite smartly to allow shortcuts to work irrespective of the current input
method/language. 

It's not simply Russian or Hebrew being affected, any language that produces
different keycodes for shortcuts other than English are affected.
Therefore, add Greek to the list and expect more.

Comment 19

[Philip Withnall (unavailable)]

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

Comment 20

[Filip Miletic]

Add Serbian to this.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This bug should be fixed by bug 359638 and related bugs. Can somebody reproduce this bug on Fx3 or trunk build?

Comment 22

[Karl Tomlinson (:karlt)]

I think this is only resolved for Latin accesskey shortcuts.

There is still the question of whether non-Latin shortcuts (in localized menus for example) should be activated from keyboard layouts that do not support the local script.

Comment 23

[Valery Kondakoff]

The bugs https://bugzilla.mozilla.org/show_bug.cgi?id=87253, https://bugzilla.mozilla.org/show_bug.cgi?id=518786 and https://bugzilla.mozilla.org/show_bug.cgi?id=177508 are here for around a ten years... If there is a chance they will draw a developers attention? Shouls they be combined in a single bug?

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Moving all open Keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.