CTRL + W is not working while keyboard layout is on Hebrew

[hidro]

Binary package hint: firefox-3.0

Ubuntu 8.04
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0

ProblemType: Bug
Architecture: i386
Date: Wed Jun 11 19:00:06 2008
DistroRelease: Ubuntu 8.04
Package: firefox-3.0 3.0~rc1+nobinonly-0ubuntu0.8.04.1
PackageArchitecture: i386
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-18-generic i686

[Shriramana Sharma (jamadagni)]

I think the developers will expect more details than this. Are you using GNOME or KDE? And is the Hebrew keyboard layout implemented in GNOME or KDE or using Scim/Skim? On my system I use Indian language keyboard layouts using Skim on KDE but Ctrl+W (and other shortcuts for that matter) work properly.

[hidro (hidroo)]

GNOME implemented hebrew.
this bug didn't occur in ff3 beta 5

[Alexander Sack (asac)]

On Wed, Jun 11, 2008 at 04:10:46PM -0000, hidro wrote:
>
> ** Attachment added: "Dependencies.txt"
> http://launchpadlibrarian.net/15199984/Dependencies.txt
>
> ** Attachment added: "ExtensionSummary.txt"
> http://launchpadlibrarian.net/15199985/ExtensionSummary.txt

first, please try to disable your extensions in tools -> addons and
see if your issues go away. (well except the hebrew translation
extensions and ubunto firefox modifications obviously).

 status incomplete

 - Alexander

[hidro (hidroo)]

all is disabled and nothing changed

[nathan (nathankras)]

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008061702 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008061702 Minefield/3.1a1pre

All shortcut keys are mapped to their qwerty equivalents, rather than the correct colemak keys. For example, pressing cmd-l to go to the address bar, is the equilivant to cmd-u, and opens up the page source. (In colemak, the key at qwerty position 'u' is an 'l'. Obviously the issue does not occur with keys that are the same in both qwerty and the alternate layout, like q or w or a.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Make sure that firefox is using an english keyboard layout other than qwerty or dvorak
3. Use a keyboard shortcut that uses a key that is different between the current layout and qwerty. For example, cmd-t (qwerty f) causes this.
Actual Results:
The shortcut activated was incorrect, it executed the qwerty shortcut. In the example, this shortcut was cmd-f, which opened the find dialog.

Expected Results:
The shortcut for colemak should have bene activated. In the example, this should have opened a new tab.

I am using the colemak keyboard layout. It should be fixed to work with any keyboard layout, not just colemak, qwerty, and dvorak.

[Mats Palmgren (matspal)]

Dupe of bug 434737?

[hidro (hidroo)]

it is still not working

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0

[nathan (nathankras)]

The dvorak layout works now with the hotkeys I checked (on Mac OS X). The issue is with layouts other than qwerty and dvorak on Mac OS X. This bug isn't a dupe of 434737.

[Alexander Sack (asac)]

On Wed, Jun 18, 2008 at 06:22:04AM -0000, hidro wrote:
> it is still not working
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015
> Firefox/3.0
>

Does Hebrew has a "W" key at all?

 - Alexander

[hidro (hidroo)]

yes the keyboard hes a " w / ' " key

[Tgj63rfisp (tgj63rfisp)]

We have the same issue on Windows too.
Using an alternative keyboard layout like dvorak all keyboard shortcuts are missmapped (i.e. they are mapped for qwerty).
So, this issue can be reproduced on Mac and on Windows.

[Daveysnack-moz (daveysnack-moz)]

I can confirm this issue on Windows XP. I am using a Dvorak layout where CTRL keys revert to QWERTY. In Firefox, however, if I select text and enter CTRL-C to copy, Firefox treats it as CTRL-J (what the key would be in Dvorak if I didn't have the CTRL override) and opens the Downloads window. Similarly, if I enter CTRL-V, Firefox treats it as CTRL-K and changes the focus to the search bar.

However, the problem does not occur in form text fields, in the address bar, or in the search bar.

This also wasn't a problem in Firefox 2, nor do I have this problem in other applications.

This is a particularly annoying bug as I often wish to copy text from web pages, and right now I must resort to the context menu rather than a keyboard shortcut.

[Zazcallabah (zazcallabah)]

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

[Neilcczwdr (neilcczwdr)]

well, I was hoping that by now Firefox 3 is ready to use and the most annoying bugs have been resolved...
Now imagine my surprise when I tried Firefox 3.0.1 now
only to discover that Firefox 3 is still NOT ready to use!
WTF???
How is it even possible for such an annoying bug like this one
to be in the version 3.0.1 ???
I too use the dvorak keyboard layout and I can't believe this bug hasn't been fixed yet?

[Raulcmr3qc (raulcmr3qc)]

Yes, I can confirm this too. it's very annoying.
I'm using dvorak.

[Claudels00ht (claudels00ht)]

well first I thought I was doing something wrong but now I see it's just a bug?
well I have to agree with the above poster
it's a particularly annoying bug.
is there any kind of a work-around yet?
every time I want to copy something the download window jumps at me!

[Nancygrimm29 (nancygrimm29)]

I just did a Google search and found a blog post with a link to this page. I'm having the same problem as the other people here. Can anyone tell me how/where can I switch back to Firefox 2?
I use copy&paste shortcuts quite a lot and I need to switch back to Firefox 2 because I can't use them in Firefox 3.
Thanks.

[Russcru445956 (russcru445956)]

Hello, I have the same problem on Windows XP with a dvorak keyboard layout.
keyboard shortcuts are broken.

[Willardzrznrs (willardzrznrs)]

The dvorak layout does NOT work on Windows!!! I mean I can type but ALL the keyboards shortcuts are BROKEN!!!!!!!!!!!

[Ar1alexanders (ar1alexanders)]

Having the same issue here on windows with dvorak keyboard layout.
every time I hit CTRL-C to copy something a download windows opens...
well looks like Firefox isn't ready for production use.
I'm going to switch back to Opera now but when they fix this issue I'm like to test Firefox one more time.

[Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

Spinnoff of Bug #69230.

It appears that a new regression in Firefox 3.x prevents some, but not all, keyboard accelerators from working in specific keyboard layouts.

With a Hebrew keyboard layout, I can confirm that CTRL-Q and CTRL-W do not work, though CTRL-A, Z, X, C, V, P, F, H, B, and L do work as expected. Other users are encouraged to specify their keyboard layout here, and to specify which keyboard accelerators do work and which do not.

Reproducible: Always

Steps to Reproduce:
1. Enable non-US keyboard layout
2. Press accelerator key combination

Actual Results:
Nothing happens

Expected Results:
Accelerator combination should perform it's function

[Ndemou-gmail (ndemou-gmail)]

ALL accelerators mentioned (plus Ctrl-T) work fine with Greek keyb layout on Ubuntu Firefox/3.0.1 -- Mozilla/5.0 (X11; U; Linux i686; el-GR; rv:1.9.0.1) Gecko/2008072820

[Eyalroz (eyalroz)]

Ctrl+W works for me with FF 3.0.1 and Hebrew layout on Win XP. Don't remember Ctrl+Q should be doing...

[Haggai Eran (haggai-eran)]

I'm using Firefox 3.0.1 on Ubuntu linux, and I can confirm Dotan's report that Ctrl-W and Ctrl-Q doesn't work when the current keyboard layout is Hebrew.

Regards,
Haggai

[Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen)]

I am also using Ubuntu Linux with Firefox 3, so this may be a Linux-specific or Ubuntu specific issue.

[Smontagu (smontagu)]

I can only reproduce this on Linux (also Ubuntu). Note that Q and W are keys that are not mapped to alphabetical characters in the Hebrew layout.

[Yehudab (yehudab)]

Reproduced using CentOS 5.2, and Hebrew layout.
Everything works except Ctrl-W and Ctrl-Q.

[Tomer Cohen (tomer-gmx)]

(In reply to comment #5)
> I can only reproduce this on Linux (also Ubuntu). Note that Q and W are keys
> that are not mapped to alphabetical characters in the Hebrew layout.

smontagu: Do you have any idea if and how we can fix it?

[Tomer Cohen (tomer-gmx)]

Adding the 'intl' keyword. Someone should do a batch run to replace every bug with the 'i18n' keyword with 'intl' since we don't have that keyword any more...

[Smontagu (smontagu)]

Created an attachment (id=336634)
Possible patch

A bit hacky, but it works. It's unfortunate that mochitests for keyhandling don't cover GTK

[Masayuki (masayuki)]

The patch is pretty hacky.

I think that when '/' or ''' key is pressed, we should go to |if (!isLatin)| block.

It seems that one of unshifted char and shifted char is alphabet but other is not so, then, we should go to the block.

[Smontagu (smontagu)]

Created an attachment (id=336660)
Patch v.2

Do you mean like this? This is what I wanted to do in the first place, but I didn't want to revert the change from is_latin_shortcut_key to (code <= 0xFF) in bug 359638.

I've tested that this doesn't regress bug 427932 or bug 433192. Can you suggest other scenarios I should be testing?

[Masayuki (masayuki)]

No. I think:

+ PRBool needLatinKeyCodes = !isLatin;
+ if (!needLatinKeyCodes) {
+ PRBool isAlpha1 = NS_IS_ALPHA(altCharCodes.mUnshiftedCharCode);
+ PRBool isAlpha2 = NS_IS_ALPHA(altCharCodes.mShiftedCharCode);
+ needLatinKeyCodes = (isAlpha1 && !isAlpha2) || (!isAlpha1 && isAlpha2);
+ }

- if (isLatin) {
+ if (needLatinKeyCodes) {

I believe this is safest way for other key layouts...

[Karlt (karlt)]

(In reply to comment #12)
> + PRBool needLatinKeyCodes = !isLatin;
> + if (!needLatinKeyCodes) {
> + PRBool isAlpha1 = NS_IS_ALPHA(altCharCodes.mUnshiftedCharCode);
> + PRBool isAlpha2 = NS_IS_ALPHA(altCharCodes.mShiftedCharCode);
> + needLatinKeyCodes = (isAlpha1 && !isAlpha2) || (!isAlpha1 && isAlpha2);
> + }
>
> - if (isLatin) {
> + if (needLatinKeyCodes) {

NS_IS_ALPHA uses isalpha, which depends on locale, so may produce some
surprises.

We also need to be careful about changing event.charCode if there is a Latin
character is the current group. If Ctrl-/ is a meaningful shortcut, then I
guess it should be preferred over Ctrl-Q (with Ctrl-Q tried as fallback).

Simon, Dotan, Eyal, Haggai, or Yehuda, or Tomer, tell me if a Hebrew user
would think otherwise?

I can think of two possible alternatives for needLatinKeyCodes:

a) Provide the basic Latin letter or numeral as an alternative when and only
   when that basic letter or numeral is not available on level 0 of the
   current group, or

b) Look for a basic Latin letter or numeral only when the current group does
   not look like a Latin layout. That perhaps can be tested through looking
   for one or more specific Latin letters on level 0 of the current layout. I
   wonder whether any layouts have an "a" but not the rest of the Latin
   alphabet. I wonder whether any Latin layouts do not have "z".

[Masayuki (masayuki)]

(In reply to comment #13)
> NS_IS_ALPHA uses isalpha, which depends on locale, so may produce some
> surprises.

NS_IS_ALPHA also checks whether the char is ASCII. So, if the result is true, should be ASCII alphabets.

> We also need to be careful about changing event.charCode if there is a Latin
> character is the current group. If Ctrl-/ is a meaningful shortcut, then I
> guess it should be preferred over Ctrl-Q (with Ctrl-Q tried as fallback).

We should not modify charCode. I think Ctrl+'/' should win. Because if Ctrl+'Q' wins, Ctrl+'/' cannot be accessible. Of course, all UI developers should not use non-alphabets and non-numeric keys for shortcut.

I think that win32 build behaves so, perhaps.
We should use same processing on all platforms if we can.

[Karlt (karlt)]

(In reply to comment #14)
> NS_IS_ALPHA also checks whether the char is ASCII.
> So, if the result is true, should be ASCII alphabets.

It checks whether the char is <= 0x7f. Locale also includes the charmap. If every charmap has the same (ASCII) meaning for the first 0x7f characters, then it should be safe. But I don't know whether that is a safe assumption.
("locale -m" gives a list of available charmaps.)

[Masayuki (masayuki)]

(In reply to comment #15)
> (In reply to comment #14)
> > NS_IS_ALPHA also checks whether the char is ASCII.
> > So, if the result is true, should be ASCII alphabets.
>
> It checks whether the char is <= 0x7f. Locale also includes the charmap. If
> every charmap has the same (ASCII) meaning for the first 0x7f characters, then
> it should be safe. But I don't know whether that is a safe assumption.
> ("locale -m" gives a list of available charmaps.

We should use |('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z')| ?

[Karlt (karlt)]

(In reply to comment #16)
> We should use |('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z')| ?

I'd feel safest with that.

[Smontagu (smontagu)]

(In reply to comment #14)
> We should not modify charCode. I think Ctrl+'/' should win. Because if Ctrl+'Q'
> wins, Ctrl+'/' cannot be accessible. Of course, all UI developers should not
> use non-alphabets and non-numeric keys for shortcut.

I was surprised to discover that Ctrl+/ is a shortcut for "Select All" in text fields on GTK. This is rather unpleasant: if a text field is focused, Ctrl+/ is meaningful but Ctrl+' is not; otherwise neither is meaningful. If we say that the non-alpha shortcut wins iff it is meaningful, the same key combination will be "Select All" when focus is in a text field and "Quit" when it is elsewhere, which is a combination that could easily cause data loss if a user enters text, unfocusses the text field without realising and then tries to select all.

On the other hand, if the non-alpha shortcut always wins (the status quo), Ctrl-W and Ctrl-Q are inaccessible in the Hebrew layout.

In the specific case of the Hebrew layout, I'm fairly sure that users expect these keys to produce Ctrl-Q and Ctrl-W, not Ctrl-/ and Ctrl-', and it's also not the end of the world if Ctrl-/ is inaccessible, since it's synonymous with Ctrl-A. We need to check whether other layouts will be affected, though.

[Haggai Eran (haggai-eran)]

I agree with Simon, that as a Hebrew user, I expect the shortcut to stay in their places even when I change the current layout. This means that Ctrl-Q should be preffered over Ctrl-/.
I'm not sure this must mean that Ctrl-/ is inaccessible. The Hebrew keyboard layout has '.' instead of '/' , so why can't Ctrl-. mean Ctrl-/ when the Hebrew layout is selected?

[Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen)]

@Karl:
> We also need to be careful about changing event.charCode if there
> is a Latin character is the current group. If Ctrl-/ is a meaningful
> shortcut, then I guess it should be preferred over Ctrl-Q (with
> Ctrl-Q tried as fallback).

I'm not sure that I understand, but the Latin Ctrl-/ shortcut I have never heard of. I say that as a keyboard power user, so I feel reasonably confident that it is a rather unknown shortcut. Personally, I would have no problem with Ctrl-Q NOT working in Hebrew, as I have only ever hit it by accident and I think that an operation as deadly as closing the app should not have a keyboard shortcut, especially when that key borders three very common shortcuts: Ctrl-W, Ctrl-A and Ctrl-TAB. That said, Ctrl-W is a critical shortcut that we do need.

Would it be reasonable to suggest that we sacrifice Ctrl-Q in the Hebrew layout for these two reasons:
1) It may interfere with another shortcut (Ctrl-/)
2) It is a dangerous and seldom-used shortcut

[Spamcop (spamcop)]

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

[Spamcop (spamcop)]

@Everyone:
Please note that this bug is about Fx on MacOS X. I know that Windows has the same problem, but the Windows problem is most likely not related to this one. This problem resolves in Leopard (Mac OS 10.5) and is only observed in Tiger (Mac OS 10.4); so it must have to do with some Mac OS system internals that Apple has changed between 10.4 and 10.5 and with the way how Fx is using them (as other apps are not affected by that issue, neither in 10.4 nor 10.5). The Windows issue is pretty much the same as the one described here, but I doubt anything that will magically fix by a future Windows version (as this bug did for Mac OS X). There is a different bug for this problem regarding Windows and your Windows comments should probably go there.

I have been using Dvorak on Mac since 10.3 and never had a problem with Fx 2 or Fx 3. Right now I use 10.4 and when I use QWERTY, the shortcuts work right and when I use Dvorak, they work right as well (e.g. CMD+P brings me to the location bar, what is expected, as Dvorak has L on the P key). So Dvorak is no problem.

However, recently I discovered a new, interesting layout, that aims on improving QWERTY layout and at the same time to fix some problems Dvorak has, called Colemak:

http://colemak.com/

I installed this layout on my Mac and am currently playing around with it a little bit. When I use this layout on Tiger, I have exactly the same problem as what people describe here. E.g. opening a new tab still happens when I type CMD+T, however on Colemak, the T key is actually a the G key, so this shouldn't work. But if I hit CMD+F (which is where Colemak puts the T key), I start a new search. So even though all my text input everywhere in the app is Colemak, shortcuts are still QWERTY... what is extra strange, as I'm actually only switching between Dvorak and Colemak and never use QWERTY at all!??

So Colemak is showing the problems other people are reporting here. And I can also confirm, that using Leopard (10.5) I have no problems at all whatsoever. In Leopard even the Colemak shortcuts work right in Fx 3.

Someone on the Colemak page has suggested, it has to do with Cocoa and Carbon. But this cannot be right. Filemaker is also just Carbon, no Cocoa and there Colemak shortcut works fine as well. I only have the Colemak shortcut Problem in Fx and in no other app I use, may it be Cocoa or Carbon.

[Ar1alexanders (ar1alexanders)]

I disagree:
This bug is NOT just about MacOS X!
I have the very same bug on Windows XP (and dvorak keyboard layout)
and as you can read above other people have the same bug too - on WINDOWS.

[Ar1alexanders (ar1alexanders)]

p.s.
this bug only appeared in Firefox 3.0
in earlier versions there were never such problem.

So, my conclusion is:
It is NOT and never was a MacOS problem.

And WHY it *appears* as if it was a MacOS problem?
BECAUSE: Most (or at least MANY) Apple engineers are using dvorak layout for themselves for DECADES! (just make some research if you don't believe it)
But apparently no one of the Mozilla engineers is using this layout.
(even though it's a much better keyboard layout)

So, obviously Apple engineers were so annoyed by this Firefox bug
that they have fixed it IN THEIR OS!
They obviously fixed a Firefox bug in their operating system!

That's why this bug disappeared in Mac OS 10.5
and that's why this bug is still there for colemak:
BECAUSE it was NEVER fixed in Firefox!

[Ar1alexanders (ar1alexanders)]

Oh, and by the way:
I'm using the *intelligent* version of the dvorak layout.
That is:
Normally all characters on keyboard are assigned as in the dvorak layout.
But when I press the CTRL key it switches automatically to the Querty Layout!
That way all the familiar shortcuts like CTRL+C, CTRL+V etc.
are in the same place an in the standard Querty keyboard.

So, there is no need for colemak with this intelligent version of dvorak.

p.s.
As far as I know dvorak layout that ships with windows has automatically
this intelligent dvorak version built in.
(I've built a custom version of dvorak because I added a few special character keys)

[Spamcop (spamcop)]

@Alex: The code for handling keyboard input is platform dependent AFAIK, and that means it is entirely different code for Windows and MacOS. You can argue with as long as you like, but you will see, if this bug has been fixed for MacOS X, the Windows bug will still persist, as the Windows bug needs to be fixed in the Windows code of Fx and the MacOS bug in the MacOS code of Fx. Just because the same problem is seen on different platforms doesn't make it the same bug.

Further the Colemak bug is not there on 10.5, which renders your theory completely false. Colemak shortcuts work just fine on 10.5 (so it has nothing to do with Apple developers using Dvorak or not using it and I doubt Apple has made any fixes for Fx in 10.5 to make Colemak work, especially since Apple does not even ship Colemak among their selectable keyboard layouts).

Last but not least, this is no discussion forum, so please refrain from spamming bugs with chitchat. Whether there is a "need" for Colemak or not is totally irrelevant to this bug and basically your personal opinion. I don't use Colemak because of any keyboard shortcuts (and I also don't use smart Dvorak as you call it), I use it, because pretty much any usability test I used to compare it to Dvorak showed that it is better on average. And the bug is also not about Colemak. The bug is about "Custom Keyboard Layouts not working in Fx on 10.4". I can create an own keyboard layout using Ukelele and it has exactly the same problem in 10.4 and it does not have this problem in 10.5 (and since I made the layout myself, how do you expect Apple to have fixed something for a layout in 10.5 which I just invented myself 15 minutes ago?)

[Ar1alexanders (ar1alexanders)]

@spamcop:
OK, than proves, of course, that my theory is completely false.

But then my question is:
What have I to do now as a Windows user??

Will Firefox developers fix the Windows bug (which is VERY similar to this one) as well or do they need an extra bug report for windows or something?

[Spamcop (spamcop)]

@Alex: The bug you report seems to be a pretty old one, at least users have reported this already long before Fx 3 was released. See bug 311665 for example. If you think this is not your bug, I'd file a new one.

Now back to the actual Mac bug. I got a copy of the Fx source code and this is what I found:

  if (nsToolkit::OnLeopardOrLater() && !Leopard_TISCopyCurrentKeyboardLayoutInputSource) {
    void* hitoolboxHandle = dlopen("/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Versions/A/HIToolbox", RTLD_LAZY);
    if (hitoolboxHandle) {
      *(void **)(&Leopard_TISCopyCurrentKeyboardLayoutInputSource) = dlsym(hitoolboxHandle, "TISCopyCurrentKeyboardLayoutInputSource");
      *(void **)(&Leopard_TISGetInputSourceProperty) = dlsym(hitoolboxHandle, "TISGetInputSourceProperty");
      *(void **)(&Leopard_TISCreateInputSourceList) = dlsym(hitoolboxHandle, "TISCreateInputSourceList");
      kOurTISPropertyUnicodeKeyLayoutData = *static_cast<CFStringRef*>(dlsym(hitoolboxHandle, "kTISPropertyUnicodeKeyLayoutData"));
      kOurTISPropertyInputSourceID = *static_cast<CFStringRef*>(dlsym(hitoolboxHandle, "kTISPropertyInputSourceID"));
    }
  }

So there is some code regarding keyboard handling, that is only executed on Leopard, not on Tiger. Maybe some code like this makes the difference and maybe this is the reason why it works on Leopard, but not on Tiger (see Alex, this might be totally platform dependent code, the code above is certainly not executed under Windows).

I will further investigate that. I'm not a Fx developer, but I'm a Mac programmer and since currently nobody is working on this bug at all, it's better someone is doing something than no one is.

[Spamcop (spamcop)]

I might be totally wrong, but this code also looks rather suspicious to me:

 // Is the keyboard layout changed by Cmd key?
 // E.g., Arabic, Russian, Hebrew, Greek and Dvorak-QWERTY.
 PRBool isCmdSwitchLayout = uncmdedChar != cmdedChar;
 // Is the keyboard layout for Latin, but Cmd key switches the layout?
 // I.e., Dvorak-QWERTY
 PRBool isDvorakQWERTY = isCmdSwitchLayout && kt.mScript == smRoman;

Assuming that just because a keyboard layout switches when CMD is pressed and it is Latin script, it must automatically be Dvorak-QUERTY seems utterly wrong to me (or maybe the variable naming is just poor).

I could probably find out what goes wrong, if I only had a debug build of Fx. I can't install ports, hence I can't build it myself. I think it's really poor that Mozilla does not provide unstripped builds ready to use on their server!

[Spamcop (spamcop)]

Found the bug :-) Not the actual cause for it, but I see what goes wrong. It was quite PITA to get Fx to compile on my Mac, oh dear.

in the old days of OSX, Apple offered a function to translate keycodes to characters, named KeyTranslate (now legacy):

http://developer.apple.com/documentation/mac/Toolbox/Toolbox-78.html

This was for keyboards in 'KCHR' format (legacy as well). The new function, working with the new XML keyboard format ('uchr' format) is named UCKeyTranslate:

http://developer.apple.com/documentation/Carbon/Reference/Unicode_Utilities_Ref/Reference/reference.html#//apple_ref/doc/c_ref/UCKeyTranslate

Firefox can work with either one. Here's some original Fx code:

static PRUint32
GetUniCharFromKeyTranslate(KeyTranslateData& aData,
                           UInt32 aKeyCode, UInt32 aModifiers)
{
  if (aData.mUchr.mLayout) {
    return UCKeyTranslateToUnicode(aData.mUchr.mLayout, aKeyCode, aModifiers,
                                   aData.mUchr.mKbType);
  }
  if (aData.mKchr.mHandle) {
    return KeyTranslateToUnicode(aData.mKchr.mHandle, aKeyCode, aModifiers,
                                 aData.mKchr.mEncoding);
  }
  return 0;
}

So it will call either one, or the other one. I just tested that with GDB. When using Dvorak layout, it calls the second one (the old legacy one), but that might be okay (maybe Apple still ships their own keyboards in the KCHR format). However, when using Colemak, it also calls the second one - and I consider this the bug! Colemak is definitely no KCHR format, it is uchr format (actually XML, but the XML is translated to uchr on load); so it should call the first one. As I said, not sure what the real source of this bug is, but I guess it would work, if Fx was just calling the right function. Other keyboards that only exists in uchr is US International for example and a couple of very exotic ones (trying to say here: Even Apple ships some keyboards only in that format, by far not every keyboard has a KCHR format available).

In whatever way Fx tries to detect which function to use, this seems to work on 10.5, but not on 10.4. Since I'm no Fx developer, maybe some real developer can come here and help us a little bit. I'd really like to see some progress and I'm really doing the best I can, but I will need some help with that. Please :'(

[Spamcop (spamcop)]

Created an attachment (id=339288)
GDB session, showing were things go wrong

[Spamcop (spamcop)]

One more interesting pointer: Apple says what Firefox is doing is not supported at all!

http://lists.apple.com/archives/carbon-dev/2005/Jan/msg00527.html

Access to keyboards via the Resource Manager is no longer supported and hasn't been since Jaguar. Use the Keyboard Layout Services APIs instead:
http://developer.apple.com/documentation/Carbon/Reference/KeyboardLayoutServices/index.html

But this is exactly what Fx tries. I tries to load the uchr resource using resource manager (uchr) and Apple says that can't work. Then it tries to load it again using resource manager (kchr) and this fails as well and finally it falls back to some cached layout, which seems to always be QWERTY, and that pretty much explains the bug I think. Here's the relevant code:

Handle handle = ::GetResource('uchr', kt.mLayoutID);
      if (uchr) {
        kt.mUchr.mLayout = reinterpret_cast<const UCKeyboardLayout*>
          (CFDataGetBytePtr(uchr));
      } else if (handle) {
        kt.mUchr.mLayout = *((UCKeyboardLayout**)handle);
      } else {
        kt.mKchr.mHandle = ::GetResource('kchr', kt.mLayoutID);
        if (!kt.mKchr.mHandle && !gOverrideKeyboardLayout.mOverrideEnabled)
          kt.mKchr.mHandle = (char**)::GetScriptManagerVariable(smKCHRCache);
        if (kt.mKchr.mHandle) {
          OSStatus err =
            ::GetTextEncodingFromScriptInfo(kt.mScript, kTextLanguageDontCare,
                                            kTextRegionDontCare,
                                            &kt.mKchr.mEncoding);
          if (err != noErr)
            kt.mKchr.mHandle = nsnull;
        }
      }

Further I attached a GDB debug session, where I step exactly through this code to show the problem.

For Leopard a different code is ran before the code above and this code seems to work correctly, it finds the uchr resource (so the code above rans into the first IF) and uses it and from there on, everything works as expected.

[Spamcop (spamcop)]

Okay, I fixed it. The new version of the code looks like this (the whole patched file is attached as well). Please note, that this whole keyboard handling code is a mess. Sorry, I don't want to be insulting here, but this code looks horrible to me and I wonder why Fx can run anything but fast with such a bad code being called twice for *EVERY KEY* you press! The whole code needs a clean up, however, I don't feel like doing that at the moment, since I must admit, I don't really know what I just did there, I don't even understand half of it (the more it is surprising, that this actually works :P). It should separate between Tiger and Leopard on the very top of the function, use the methods I use for Tiger only and the new TIS functions for Leopard that it already uses right now. Also I don't understand what this whole "overwrite keyboard" stuff means or what it is good for (why would Fx overwrite my layout for any reason?).

Also I'm not quite sure about certain casts I do. The casts I do when calling KLGetKeyboardLayoutProperty() might be totally wrong. They work for Dvorak and Colemak just fine on my Mac, but I'm not sure if you may just cast once UCKeyboardLayout** to const void ** (this one might be reasonable) and once char*** (being Handle *) to const void ** as well. So this code might as well crash on certain systems or with certain keyboard layouts, don't take my word for it that this is really correct code! Bless God that all the code I added is mainly necessary for 10.4 only and it all deprecated in 10.5 and has been replaced by Apple with completely new functions. So in no case try to copy that code really to the CVS, it's mainly an example of how the code could possibly look like.

if (uchr) {
  kt.mUchr.mLayout = reinterpret_cast<const UCKeyboardLayout*>
    (CFDataGetBytePtr(uchr));
} else {
  KeyboardLayoutRef keyboard;
  OSStatus err = KLGetKeyboardLayoutWithIdentifier(kt.mLayoutID, &keyboard);
  if (err == noErr) {
    err = KLGetKeyboardLayoutProperty(keyboard, kKLuchrData, (const void **)&(kt.mUchr.mLayout));
    if (err != noErr || !kt.mUchr.mLayout) {
      err = KLGetKeyboardLayoutProperty(keyboard, kKLKCHRData, (const void **)&(kt.mKchr.mHandle));
      if (err != noErr || !kt.mKchr.mHandle) {
        kt.mKchr.mHandle = nsnull;
      } else {
        OSStatus err =
          ::GetTextEncodingFromScriptInfo(kt.mScript, kTextLanguageDontCare,
                                          kTextRegionDontCare,
                                          &kt.mKchr.mEncoding);
        if (err != noErr) {
          kt.mKchr.mHandle = nsnull;
        }
      }
    }
  }
}

[Spamcop (spamcop)]

Created an attachment (id=339316)
This code works correct for me with Dvorak and Colemak

[Spamcop (spamcop)]

I can't believe it. This bug affects users, probably more than just Colemak users (pretty much every user whose keyboard layout has no KCHR resource on 10.4), I spent a lot of time in debugging the problem and finding the source, which is that the current code is entirely wrong/broken according to Apple. I spent even more time finding out how the right code would look like and writing a minimal patch the solves the issue on every system where I have tested the patch. While this is no ready to use patch, it hands the solution on a silver platter... and still, over half a month later, not even a single Mozilla developer took himself the time to even *LOOK* into that issue. What's wrong? Has Firefox development stopped completely once and for all? Are bugs not interesting anymore? Or isn't it considered a real bug anymore if all keyboard navigation is broken for users? Can anyone maybe comment on this? Anyone still there?

[Zeniko (zeniko)]

(In reply to comment #26)
> This code works correct for me with Dvorak and Colemak

Thanks for your contribution. However please read <http://developer.mozilla.org/en/Hacking_Mozilla> before attaching code.

Executive summary: Please post patches as unified diffs and then ask an appropriate person for review (in this case either Masayuki Nakano <email address hidden> or Karl Tomlinson <email address hidden>).

[Ar1alexanders (ar1alexanders)]

When you guys try to solve this please also test with the Dvorak keyboard layout.
Because several users reported in this ticket here: https://bugzilla.mozilla.org/show_bug.cgi?id=439815 (which turned out to be a Mac only bug)
that they have these shortcut issues on Windows with the Dvorak keyboard layout.

I've tested that too and *ALL* keyboard shortcuts were broken with Dvorak layout.
The whole thing is especially annoying when you have such shortcuts as CTRL+C, CTRL+V etc. broken...

So, please test with Dvorak layout!
That might help to solve the issue entirely.

[Tomer Cohen (tomerc)]

This bug caused because W is mapped to ' in Hebrew, and Q is mapped to /.

This issue is known in Mozilla, and has a patch there waiting for review. Reporter, next time, PLEASE look for upstream bugs before reporting your own.

[Masayuki (masayuki)]

(In reply to comment #18)
> On the other hand, if the non-alpha shortcut always wins (the status quo),
> Ctrl-W and Ctrl-Q are inaccessible in the Hebrew layout.

In this case, Ctrl-W and Ctrl-Q should be accessible by Ctrl-Shift-W and Ctrl-Shift-Q. Doesn't work so?

> In the specific case of the Hebrew layout, I'm fairly sure that users expect
> these keys to produce Ctrl-Q and Ctrl-W, not Ctrl-/ and Ctrl-', and it's also
> not the end of the world if Ctrl-/ is inaccessible, since it's synonymous with
> Ctrl-A. We need to check whether other layouts will be affected, though.

If most Hebrew users think that alphabets should always win, we should do so. But then, we may make / and ' are accessible when Shift key is pressed.

[Haggai Eran (haggai-eran)]

(In reply to comment #22)
> (In reply to comment #18)
> > On the other hand, if the non-alpha shortcut always wins (the status quo),
> > Ctrl-W and Ctrl-Q are inaccessible in the Hebrew layout.
>
> In this case, Ctrl-W and Ctrl-Q should be accessible by Ctrl-Shift-W and
> Ctrl-Shift-Q. Doesn't work so?

You are assuming that all users have their shift key mapped to temporarily switch back to English keyboard. Perhaps its true for most users but not all. For instance, the variant lyx of the Hebrew keyboard on Linux is used to enter diacritics when the shift key is pressed.

[Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen)]

As mentioned on this page:
http://lindesk.com/2008/12/kde-vs-gnome-a-dvorak-users-perspective/

Gnome temporarily switches to Qwerty when an accelerator key is pressed. As both Gnome and Firefox are GTK based, couldn't Firefox do the same? This does look like the ideal solution.

[Tomer Cohen (tomer-gmx)]

(In reply to comment #24)
> Gnome temporarily switches to Qwerty when an accelerator key is pressed.
Why should we? When I'm pressing Ctrl-P for print or Alt-F for File menu, I want it to be the same letter as without the accelerator. In case I have Dvorak letters printed on my keyboard, I won't have a clue where is the F letter is hiding in Qwerty (well... kind of).

[Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen)]

@Tomer: That's why it should be optional.

[Masayuki (masayuki)]

> [DUPE of bug 452393?]

No, bug 452393 is a bug on Linux. This bug should be only for Mac.

spamcop:

Would you attach a diff of the patch on latest trunk, and request a review to me?
# see comment 28.

[Spamcop (spamcop)]

I actually didn't intent to fix this issue. I'm neither an expert on this topic, nor do I have any C++ knowledge (I know plain C, I know Objective-C, but C++ is not my game). All I did was looking at the code and trying to find out why it fails. The information I needed for that could all be found in Apple's online documentation and on their mailing list. I thought when I just show people here "how it is done", someone of the developers responsible for this module can use my example code to actually create a real fix for the issue. Looks like I was wrong.

The reason why it fails is a complicated matter. Apple supports two type of keyboard drivers in OS X. The old style drivers which exists since the early days of Mac OS X (10.0 and on) and the new style drivers, which were added some times later (not sure which version). The main difference is that the new style drivers have full unicode support, the old style drivers did not. Further the old style driver format is proprietary, only Apple knows how its done (all knowledge about them was gained through reverse engineering). The new style drivers are very well documented and are intended to replace the old style drivers in the long run.

The code I found in the Mozilla project was code that works with the old style drivers... unfortunately it only works with the old style drivers. Further it uses plenty of legacy functions that Apple has all marked as deprecated. All third-party keyboard drivers are new style drivers, however. Most applications don't care what kind of drivers are used, Cocoa/Carbon UI elements automatically behave correct(TM), Apple made sure they do. However, Firefox insists on doing the task of translating a keycode to a unicode character on its own (native applications usually never have to do this). The upshot: Firefox fails to find the driver resource for the new style driver and instead translates the code via US English keyboard layout, which leads to incorrect results, of course. Only shortcuts are affected, though, as for typing input into textfields/textareas native Cocoa UI elements are used and these translate correctly in either case.

The reason why this bug never appeared on 10.5 is that Apple introduced a complete new set of API functions and Firefox actually uses these on 10.5. These function work correctly regardless of driver style and thus Colemak works just fine under 10.5 even for keyboard shortcuts. For 10.4 though, different code is needed depending whether the currently selected keyboard layout is an old-style or new-style driver. Apple admitted on their mailing list, that this is unfortunate, especially since the code you need for old-style drivers is deprecated. That's why the whole thing was replaced with a new API in 10.5

Meanwhile I upgraded to 10.5 myself, so I'm lacking the ability to really test the code... well, maybe I can build it release and then check it on a different system. Building on a different one is out of question since only my main system is fast enough to build Firefox in less than several hours. However, I fear that I may not even be able to build it any longer, since I have not installed the UNIX build environment in Xcode.

...

[Dicktyr (dicktyr)]

Why is this mistake being ignored?

The eighth update has been released yet this "bug" remains assigned to "Nobody". A patch with a clear description of the problem has been posted yet it appears to have been ignored and then dismissed for lack of procedural adherence. Is this a community or yet another case of *us* and *them*?

Please resolve this problem.

[Masayuki (masayuki)]

This bug will not be fixed on Fx3.0.x and Fx3.5.x. Because the changes for this bug is too risky for the stable branches. If I'm lucky, I'll fix this bug until the end of alpha stage of Fx3.6. But unfortunately, I don't have much time now. I'm working hard on TSF support of Windows. That needs many tests/testers until Fx3.6. So, that is my first priority work.

[Shahar Or (mightyiam)]

Dear Tomer,

I don't think that reporting here should be avoided and I don't think that users are instructed to look for the upstream report before reporting.

Many blessings.

[Tomer Cohen (tomerc)]

Shachar - As not every Mozilla contributor is monitoring every Linux distribution and other bug tracking system, issues are not assigned to the right person. In this case, we were aware of this issue, but it is possible that Mozilla will not be aware of Linux issues just because some smart people prefer to report in Ubuntu system, in which no one is monitoring and issues are never forwarded to the upstream maintainers. The only way to make things better for Ubuntu users and Linux in general is to always report issues to the right project, which is Mozilla in this case.

As you can see in the previous comments, until I pointed to the right bug in Mozilla, people here gave the reporter some advices how to get rid of the problem, which in this case won't help him, just because the other people are not aware of similar issues in Mozilla. If the reporter was searching in Mozilla, or filing a new bug (which will be than closed as duplicate) - it was much more helpful for Mozilla, and the original maintainers will be more aware of this issue and the affected users of it.

[John Vivirito (gnomefreak)]

Most Mozilla app bugs are due to upstream bugs. Its always best to look for your problem upstream unless you can pin point the problem to Ubuntu only. However we do not require you to look upstream right away. We can decide if it is Mozilla bug or our bug. We will normally ask reporters to look upstream and if you cant find one to reprot the bug upstream and drop the link to this bug report.

[Tomer Cohen (tomer-gmx)]

Issue still exists with Firefox 3.5rc2, Ubuntu Linux 9.04.

Same issue reported in Ubuntu Launchpad - https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/239222

[Masayuki (masayuki)]

Created an attachment (id=393478)
Patch v1.0

Sorry for the delay.

This patch should fix this bug and can enable the all keyboard tests on 10.4 too.

I'll post this patch to tryserver after the troubles are fixed.

[Masayuki (masayuki)]

This problem should be gone before 1.9.2 final because this is major accessibility issue for some keyboard layout users.

[Masayuki (masayuki)]

Created an attachment (id=393482)
Patch v1.0

sorry, the previous patch has unexpected change.

[Masayuki (masayuki)]

https://<email address hidden>/

Here is a test build, please check whether this bug is fixed on the build, thank you.

[Masayuki (masayuki)]

Created an attachment (id=393986)
Patch v1.1

This removes GetResource completely. The all tests in test_keybodes.xul on my environment. So, this should fix this bug completely.

If somebody can test the reported keyboard layout, please test it with test builds which will be come in tryserver.

[Masayuki (masayuki)]

> The all tests in test_keybodes.xul on my environment.

Ugh, I meant the all tests in test_keycodes.xul are passed on my environment.

[Masayuki (masayuki)]

Created an attachment (id=393992)
Patch v1.1

oops, sorry for the spam.

[Masayuki (masayuki)]

https://<email address hidden>/

The new test builds are coming here soon.

[Masayuki (masayuki)]

(From update of attachment 393992)
Unfortunately, we don't get any feedback for this patch from the reporters.

However, this patch fix the test_keybodes.xul issue on 10.4. So, this should fix the all problems for the legacy keyboard resource support on 10.4.

[Dicktyr (dicktyr)]

> https://<email address hidden>/

Thanks, seems to be working for me (10.4.11 PPC).

[Masayuki (masayuki)]

http://hg.mozilla.org/mozilla-central/rev/40f0b372a4b7

Thank you, Dick. I'll request the approval for 1.9.2.

[Masayuki (masayuki)]

(From update of attachment 393992)
Let's fix this on 1.9.2 branch.

This patch fixes the 10.4 only key hell bug on some keyboard layouts. And by this patch we can test the key handling regressions automatically on 10.4 too.

[Masayuki (masayuki)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fb7f2d569761

[shimi810 (shimi810)]

Issue still exists with Firefox 3.6, Ubuntu Linux 9.10.

[shimi810 (shimi810)]

Issue still exists with Firefox 3.6, Ubuntu Linux 9.10.

-Mozilla/5.0 (X11; U; Linux i686 (x86_64); he-IL; rv:1.9.2) Gecko/20100115 Firefox/3.6-

[Vitamin (drugcpp)]

This bug exists for almost 2 years and it isn't fixed yet? Come on...

[Tomer Cohen (tomer-gmx)]

Issue is still relevant for 3.6.x and this bug is actually has a workaround. Any chance to land it by 1.9.3?

[Vitamin (drugcpp)]

I'm also affected with this bug, and it's really annoying. Hope this will be fixed soon.

[evp55555 (evp55555)]

ubuntu 11.04, firefox 5, still the same.

[Tomer Cohen (tomerc)]

evp55555: If you want to see this issue fixed, you should do it directly on the upstream bug!

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

[Yotam Benshalom (benshalom)]

Four years, the issue is still here and is as disturbing as ever. Is there any progress?

[Tomer-moz-bugs (tomer-moz-bugs)]

Smontagu: The purposed patch you created is from 2008, and AFAIK never got committed into the tree. It might be good idea to invalidate it and re-create it for more recent Firefox version.

[Smontagu (smontagu)]

Masayuki didn't approve my patch (comment 12). I can try to produce a new one based on subsequent comments, but I'm basically too chicken to fix this bug, since my experience with keyboard bugs is that every fix breaks something else.

[Masayuki (masayuki)]

I'm going to work on reimplementing the keycode computation on Linux. If you write the patch for this, I hope you do it quickly.

FYI: the code was moved to nsGtkKeyUtils.cpp.

[Smontagu (smontagu)]

Created attachment 603986
Patch v.3

I think that Masayuki and Karl both agreed on this approach in the comments.

[Masayuki (masayuki)]

Comment on attachment 603986
Patch v.3

I believe that this improves the usability of Hebrew users at least for now, and we should land such patch ASAP because the deadline of next merge is next week.

However, I'm concerned by following situation.

If Hebrew users is using normal Hebrew layout with Dvorak, then, I think that when Ctrl+ד is pressed, the first alternative char codes are (ד, S). And second alternative char codes are (o, O). So, there is 'S' vs 'O'. I feel it's very strange. If this is not OK, it might be better to clear the 'S' from the first alternative char codes and the charCode when shift key is pressed. Anyway, this must be minor.

[Karlt (karlt)]

Comment on attachment 603986
Patch v.3

I may have felt safer if the charCode were not overridden when ascii. Ctrl-A is beginning-of-line in my settings with emacs key theme, but Ctrl-A Shift-Ctrl-E is available if Ctrl-/ is not available. I never liked having Ctrl-Q as a short cut for quit. Keyboard input does have different behaviour depending on what is focused, and I don't think we'll be able to change that.

But this is all a guessing game and my bike-shedding shouldn't get in the way of fixing Ctrl-W. Are you able to add a comment indicating that the new block takes effect in some Hebrew layouts, please?

[Smontagu (smontagu)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2f21548bcbc4

[Masayuki (masayuki)]

(In reply to Karl Tomlinson (:karlt) from comment #37)
> I never liked having
> Ctrl-Q as a short cut for quit. Keyboard input does have different
> behaviour depending on what is focused, and I don't think we'll be able to
> change that.

I think that it's not minor issue if a lot of Linux users want to use emacs like shortcut keys on Fx. At least, I think that it should be able to be disabled by pref like BackSpace key. And/Or it should show confirmation dialog.

[Mak77 (mak77)]

https://hg.mozilla.org/mozilla-central/rev/2f21548bcbc4

[Ms2ger (ms2ger)]

PRBool?

[Shahar Or (mightyiam)]

Haleluya...

[Haggai Eran (haggai-eran)]

Just added this bug to the firefox package, as firefox-3.0 is no longer available, and this bug still occurs in firefox version 11.0~b7+build1-0ubuntu1 on precise.

[Micah Gersten (micahg)]

This was fixed in Firefox 13 which will come to the stable releases when it is released.

[Micah Gersten (micahg)]

Old firefox source package in hardy is won't fix.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Emin Mastizada (emin25)]

We have same problem with Azerbaijani keyboard layout, hotkey Ctrl+W not works as its Ctrl+Ü in Azerbaijani layout.
Bug: 1116180