439815 - Keyboard shortcuts with alternate keyboard layouts (including colemak) are missmapped; they are mapped for qwerty.

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Nathan Kras]

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.

Comment 1

[Mats Palmgren (inactive)]

Dupe of bug 434737?

Comment 2

[Nathan Kras]

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. 

Comment 3

[Andy]

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. 

Comment 4

[David Adams]

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.

Comment 6

[Neil]

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?

Comment 7

[Raul]

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

Comment 8

[Claude Russell]

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! 

Comment 9

[Nancy Grimm]

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.

Comment 10

[Michael Russ]

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

Comment 11

[Willard Morgan]

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

Comment 12

[Alex Anders]

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.

Comment 14

[TGOS]

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

Comment 15

[Alex Anders]

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.

Comment 16

[Alex Anders]

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!

Comment 17

[Alex Anders]

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)

Comment 18

[TGOS]

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

Comment 19

[Alex Anders]

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

Comment 20

[TGOS]

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

Comment 21

[TGOS]

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!

Comment 22

[TGOS]

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

Comment 23

[TGOS]

Attachment: GDB session, showing were things go wrong

Comment 24

[TGOS]

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.

Comment 25

[TGOS]

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

Comment 26

[TGOS]

Attachment: This code works correct for me with Dvorak and Colemak

Comment 27

[TGOS]

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?

Comment 28

[Simon Bünzli]

(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 <[e-mail]> or Karl Tomlinson <[e-mail]>).

Comment 29

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

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

Comment 30

[TGOS]

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.

I fail to see why anyone of the educated Mozilla developers (who has a working build setup, who has a computer where he can test under 10.4 and 10.5) can download the .mm file I attached, check it against the latest trunk himself and create an acceptable patch (fixing formatting and so on) that can be reviewed. It is like somebody putting a $100 bill in front of you on the table and says "Here, take it" and what are you replying? "No sorry, this is not acceptable. Please fold it into the center and place it into my wallet". If already someone is willing to donate $100 to you, why can't you just fold it and place into your wallet?

Comment 31

[Dick]

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.

Comment 32

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

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.

Comment 33

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

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

Comment 34

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

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

Comment 35

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

Attachment: Patch v1.0

sorry, the previous patch has unexpected change.

Comment 36

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

https://build.mozilla.org/tryserver-builds/[e-mail]-bug439815/

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

Comment 37

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

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

Comment 38

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

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

Comment 39

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

Attachment: Patch v1.1

oops, sorry for the spam.

Comment 40

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

https://build.mozilla.org/tryserver-builds/[e-mail]-bug439815-2/

The new test builds are coming here soon.

Comment 41

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

Comment on attachment 393992 [details] [diff] [review]
Patch v1.1

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.

Comment 42

[Dick]

> https://build.mozilla.org/tryserver-builds/[e-mail]-bug439815-2/

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

Comment 43

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

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

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

Comment 44

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

Comment on attachment 393992 [details] [diff] [review]
Patch v1.1

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.

Comment 45

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

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