80274 - Mozilla makes Windows change keyboard mapping (ignoring substitutes?)

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Jacek Piskozub]

This is a replacement for my bug 80041, to reduce spam and make things clearer.

At least since 20010509, Win32 instaler builds confuse WindowsME into changing
the keyboard international ("language") setting from "Polish (programmers)" into
"Polish". (00010415 to 00000415). This happens the moment any keyboard input is
produced (entering any letter in URL field is enough).

As the change produces the exchange of "z" and "y" keys as well as many other
keys into the actually nonexistent "Polish" layout (no such keyboards are
actually sold any more) this will have a majro impact on Mozilla users in Poland
as well some other countries that use a different keyboard layout than the
default for the country (like Czech Republic). 

What happens? I believe that out of the two registry settings:

[HKEY_CURRENT_USER\keyboard layout\preload\1]
@="00000415"
(this defines the "Polish" keyboard) and
[HKEY_CURRENT_USER\keyboard layout\substitutes\00000415]
@="00010415"
which substitutes "Polish (programmers)" for "Polish", Mozilla reads the first,
ignoes the other and somehow confuses Windows into using the former. From this
moment on, all applications use the wrong layout.

This happens only once per Mozilla session.

Reproductibility: every time.

Steps to reproduce:

1. Choose Polish (programmers) as your default keyboard and email composition to
Central European (ISO-8859-2) - the default settings for Polish users of Mozilla
2. Open Mozilla 2001051104
3.Check in another application that you type Mozilla right
4. Start writing anything in the URL field (or probably any other text field) 
5. Check that you now type now Mozilla as "Moyilla"  ("y" and "z" exchanged)

Actual results:

Mozilla actually makes WindowsME to change the keyboard layout. It shows in
Control Panel -> Keyboard ->Language as "Polish" instead of "Polish
(programmers)". The visible results: "z" exchanged with "y", Right-Alt-letter
does not produce the Polish signs, they are now accessible by keys like "; ' [ ]"

Expected results:

Using Right-Alt-[a,s,c,o,l,z,x] should result in writing a Polish letter. The
letters z and y are where you expect them on an English/American keyboard. The
keyboard mapping is "Polish (programmers)".

Additional information:


Workaround: Change in Control Panel -> Keyboard -> Language -> Properties
"Polish" back to "Polish (programmers)" after the Mozilla induced change. It
needs to be done only once per Mozilla session (Mozilla does not do it the
second time) and luckily does not require a reboot.

It is probable that it happens with other languages/countries that use a
keyboard setting different than the oficial defaulf for the country (using the
"substitutes" registry keys.

I mark this Major as it is a big problem such the users in Poland and probably
several other countries (especially as we use the letters "y" and "z" a lot). It
could be the #1 Mozilla bug in Poland.

Comment 1

[Jacek Piskozub]

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

Comment 2

[nhottanscp]

Generic question: what is "Polish (programmers)"? Is that Polish specific (e.g.
no Spanish (programmers))?
Could you attach a screen shot of the keyboard control panel on your machine?

Comment 3

[Jacek Piskozub]

To choose it you need to use the properties button. Many countries have more 
than one keybord mapping on Windows (including actually USA!) and you choose 
them by picking the country first (as usual) and than the actual mapping in the 
Properties menu.

I ayyach a screenshot. Notice that the next entry (Portugal) has even more 
actual mappings.

Comment 4

[Jacek Piskozub]

Attachment: Control Panel -> Keyboard ->Language with the open Properties menu

Comment 5

[nhottanscp]

I still don't understand what "programmers" means.
Anyway, it might be possilbe that the problem can be reproduced with other
languages which have multiple keyboards. IQA, do we have that kind of environment?

Comment 6

[m_gerstein]

I use the "United States-Dvorak" layout.  The May 11 nightly is consistently 
switching me to the standard QWERTY "United States-101"; I think that the May 
10 and Mozilla 0.9 did the same.  This is on Windows Me.  Again, it seems to be 
insisting that I use the "standard" layout for my language, rather than the 
chosen nonstandard one.

Comment 7

[Jacek Piskozub]

> I still don't understand what "programmers" means.

OK. You asked for it.

The "Polish" keyboard is a historic layout of mechanic typewriters based on the
German one (qwertz), with Polish national characters on the rightbof letters
(where on US keyboards are signs like: [];',./). When the first PCs were
imported to Poland from the Far East - avoiding NATO sanctions that were in
place at that time - the only available keyboards were the standard qwerty ones.
Most Polish software started using the right Alt (Crtl-Alt) plus a letter (one
of the following: a, e, o, l, s, c, z, x) for the Polish characters. A few years
and a different political system later, Microsoft made the Polish version of
Windows 3.1 using this very layout which killed the old qwerz standard for good.
However as it was not the official one, sanctioned by the Polish law, in Windows
95 (and later) Microsoft gives us a choice: the official but in reality
non-existent qwertz layout ("Polish") and the real qwerty keyboard everyone uses
(as the qwertz keyboards  are no longer manufactured) which is called "Polish
(programmers)". The meaning of this is actually "computer users" ;-) I know thet
Czechs have an identical name and I suppose the histry behind this is similar.

I do not know how all this can help you but take note that no one uses the
official layout which mysteriusly takes over every time a Polish user tries to
use the recent Mozilla builds. This is highly annoying when you write "yebz"
instead of "zeby" (a big difference for some) ;-)

Comment 8

[Jacek Piskozub]

I believe that basing on m_gerstein's comment the bug should be made NEW ending
its UNCONFIRMED status.

Comment 9

[nhottanscp]

Reassign to editor group.

Comment 10

[Jacek Piskozub]

Bug 80612 is an obvious dup of this one. It involves Czech keyboard setup as
predicted in my bug description.

Comment 11

[Jacek Piskozub]

Bug 80148 is IMHO a manifestation of the same regression - you can see from the
second link in the description of #80148 that a non-default keyboard Mozilla
setting is superseded the default one while using Mozilla (notice that the same
Windows registry settings are involved). 

If they are dups, I believe bug 80148 should be a dup of this one as it has a
very narrow scope.

Comment 12

[Andreas Becker]

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

Comment 13

[Jacek Piskozub]

Bug 81329 seems a dup of this one (same Dvorak keyboard, same problem of
switching the keyboard setting to the default for a given country).

BTW, as the problem concerns already three different keyboardsettings and
Mozilla actually messes up with the OS (the keyboard change affects every
application running or even started later in the same Windows session) this bug
should be of Major severity.

Comment 14

[Jacek Piskozub]

This bug has to be fixed before the next release *or* properly described in
Release Notes

Comment 15

[edburns]

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

Comment 16

[edburns]

This bug is killing me, literally.  I have wrist pain because of this bug.

Long live DVORAK!

Comment 17

[edburns]

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

Comment 18

[Jacek Piskozub]

The dup 81329 bug was marked Blocker. Marking this one as such (at least I have
a good pretext). Maybe it will wake someone up...

Comment 19

[Rock]

This bug must be terminated with extreme prejudice. One of the builds (20010515-
09-trunk) had the keyboard layout setting change as synonomous with "Ctrl+N", 
which as every user knows will pop up a new window, causing me to switch back 
to dvorak until my eyes bleed red with anger. At any rate, good luck and 
godspeed, oh ye bugsmashers.

Comment 20

[rubydoo123]

this is not an editor issue, this should go over to Trudelle

Comment 21

[Jacek Piskozub]

A clarification: from some comments and duplicate bugs descriptions the problem
may happen many times in one session (Swedish and American Dvorak keyboards),
once in a session (WimME and Polish "programmers" keyboard). Some reporters
claim it happens every 30 minutes, other every time an applet loads. It seems it
may depend on the OS/keyboard combination.

A non-Windows bug 81638 may (or may not) be related to this one. A Linux/Mac
user (conflicting OS/Platform report) sees "?" instead of Swedish characters. It
seems the regression happened on the same day this bug surfaced - actually the
day after BIDI landed.

Comment 22

[Jacek Piskozub]

I'm pretty much sure the problem is in
mozilla/widget/src/windows/nsBidiKeyboard.cpp 

I have a very bad feeling about the code commented as follows (lines 79-81):
 
// Get the list of keyboard layouts available in the system
// Set mLTRKeyboard to the first LTR keyboard in the list and mRTLKeyboard to
the first RTL keyboard in the list
// These defaults will be used unless the user explicitly sets something else.
 
I believe our bug is exactly in the code deciding whether "the user explicitly
sets something else". 

Should someone from the BIDI team look into this bug?

Comment 23

[nhottanscp]

cc ftang

Comment 24

[nhottanscp]

Frank, please take a look at this.

Comment 25

[Frank Tang]

take a look at widget/src/windows/nsBidiKeyboard.cpp
My guess is we remember a keyboard layout, and after user switch it , mozilla 
switch it back . 
yokoyama- please take a carefull look at this . try to reproduce this first. 

Comment 26

[Roy Yokoyama]

ftang: it appears to be happening in bidi keyboard management.
I'll post a patch to disable the keyboard switch. (I am not
very proud of my patch.....)

[e-mail]: can you see if the patch fixes your problem?

simon: meanwhile, please try if you can fix correctly before 0.9.1 milestone 
( I would say by Monday morning. Taking a consideration for review process. )  
If not, then we may go ahead and check-in my patch for the time been.

Comment 27

[Roy Yokoyama]

Attachment: disabling the Bidi keyboard

Comment 28

[Roy Yokoyama]

Assigning to simon.

Comment 29

[Roy Yokoyama]

Sorry, Jacke.  I accidently assign this to you. :)  Please assign this to
[e-mail]  Thanks.

Comment 30

[Jacek Piskozub]

Correcting the assignement :-)

Comment 31

[Alexander Tsang]

I tried Yokoyama's patch in attachment 35248 [details] [diff] [review] and it has fixed the problem in bug 
80148.

Comment 32

[Simon Montagu :smontagu]

Attachment: set the keyboard properly

Comment 33

[Simon Montagu :smontagu]

The patch in attachment 35324 [details] [diff] [review] fixes this for me (testing with Hebrew, Arabic and
US-Dvorak keyboards installed). The chief problem in the original code was not
setting the KLF_SUBSTITUTE_OK flag in the call to LoadKeyboardLayout, which I
have corrected. I have also added a check of the current keyboard layout when
determining the defaults (i.e. before Mozilla has ever touched the keyboard
setting) so that the current layout becomes the default either for right-to-left
or left-to-right keyboard.

Comment 34

[Jacek Piskozub]

I finally built Win32 Mozilla from the most recent tarball + CVS + patch from
attachment 35324 [details] [diff] [review]. The original problem (change to default Polish keyboard) is
gone completely. 

Don't we need s/sr now?

Comment 35

[Frank Tang]

simon- thanks for your quick reaction. 
roy- can you review this. can you also drive the sr ?

Comment 36

[Roy Yokoyama]

simon: couple of points.
1) You may want to check the return value of ::GetKeyboardLayoutName
(localeName); to ensure the success.
2) MSDN saids that the second paramenter of ::LoadKeyboardLayout(..., 
KLF_ACTIVATE | KLF_SUBSTITUTE_OK)
 can be one of values in the table. Can we OR it?

Comment 37

[Roy Yokoyama]

simon: can we call LoadKeyboardLayout only if the target keyboard layout is 
different from the current? (see new attached patch which includes your latest
patch as well).  This prevents the flickering of input indicator (bug 81123). 

========== nsBidiKeyboard.cpp =====================================
+
+  char currentLocaleName[KL_NAMELENGTH];
+  strcpy(currentLocaleName, (aLevel & 1) ? mRTLKeyboard : mLTRKeyboard);
+  if (strcmp(mCurrentLocaleName, currentLocaleName)) {
+    if (!::LoadKeyboardLayout(currentLocaleName, KLF_ACTIVATE | 
KLF_SUBSTITUTE_OK)) {
+      return NS_ERROR_FAILURE;
+    }
+  }
+

========== nsBidiKeyboard.h =====================================
  char mRTLKeyboard[KL_NAMELENGTH];
+  char mCurrentLocaleName[KL_NAMELENGTH];
#endif // IBMBIDI
};

Comment 38

[Roy Yokoyama]

Attachment: revised: adding the check for current input layout and the target input layout

Comment 39

[Roy Yokoyama]

add [e-mail] to cc

Comment 40

[Roy Yokoyama]

Attachment: Adding error check for GetKeyboardLayoutName()

Comment 41

[Roy Yokoyama]

mkaply: can review my patch (05/21/01 14:33)?  

My only question is from my own comment (2001-05-21 11:55):
-----------
2) MSDN saids that the second paramenter of ::LoadKeyboardLayout(..., 
KLF_ACTIVATE | KLF_SUBSTITUTE_OK) can be one 
of values in the table.  Can we OR it?
-----------

I've tested and works. I just want a second opinion.

Comment 42

[Mike Kaply [:mkaply]]

r=mkaply.

The patch looks good to me

Comment 43

[Simon Montagu :smontagu]

I was also concerned that the documentation of LoadKeyboardLayout didn't seem 
to allow for ORing the flags, but it certainly works, so I think the 
documentation is just misleading.

Comment 44

[Mike Kaply [:mkaply]]

I'll take this one for checkin.

Comment 45

[Christopher Blizzard (:blizzard)]

+  if (::GetKeyboardLayoutName(mCurrentLocaleName))
+    return NS_ERROR_FAILURE;

This returns 0 on success, right?

Other than that sr=blizzard

Comment 46

[Roy Yokoyama]

blizzard:  I can't believe this.  I thought I was extra careful. ;(
Thanks for pointing it out.  

mkaply: It should read.  Can you correct before you check in?
there are two places in the code.

+  if (!::GetKeyboardLayoutName(mCurrentLocaleName))
+    return NS_ERROR_FAILURE;

Comment 47

[Roy Yokoyama]

Attachment: Correcting if (!::GetKeyboardLayoutName())

Comment 48

[Mike Kaply [:mkaply]]

Fix in

Comment 49

[Andreas Becker]

Changing QA contact to marina for now. Marina, can you take a look into this?

Reporter (Jacek), can you also try it with the latest build and check if it 
works for you?  Thanks.

Comment 50

[Jacek Piskozub]

I have been testing the new builds from yesterday evenig (first my own build)
and today the installer one. Yes, the bug is completely gone. No more keyboard
mapping changes.

Comment 51

[Jacek Piskozub]

Marking verified on my own comment (I hope that is not against the rules)

Comment 52

[Alexander Tsang]

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