User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre If you change the input locale using Left-Shift/ALT sometimes the ALT key becomes "sticky". Reproducible: Always Steps to Reproduce: 1. Place the cursor in an edit field 2. Type some letters e.g 'h' 3. Change the locale using Left-Shift/ALT 4. continue typing If you repeat this a few times the ALT key becomes sticky opening the help window instead of inserting a 'h' into the text field. Pressing ALT resolves this normally. Actual Results: Minefield should not be affected by changing the locale. Expected Results: Changing locale leads to a "sticky" ALT key. Maybe a OS problem but i can not see it with e.g. Notepad.

See also: http://forums.mozillazine.org/viewtopic.php?t=559592

Sorry, expected and actual results swapped.

This regressed between 2006-03-12 and 2006-03-07: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-12+04&maxdate=2006-03-17+09&cvsroot=%2Fcvsroot I think a regression from bug 287179.

I can confirm this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070620 Minefield/3.0a6pre - Build ID: 2007062004 Also, Shift key is also "sticky" when changing input languages (in my case English->Serbian Latin).

It's the Shift key which becomes sticky. See above the link for the thread i opened in mozillazine forums.

I have trouble to recreate the problem. I tried switching between Latvian->Russian->Greek->Finnish layouts and it always worked as expected. Can you post more details how you recreate the problem? 1. Are you pressing Alt first and then Shift or vice versa? Maybe both almost immediately? 2. How fast do you type? 3. Is CapsLock somehow involved? 4. Are these standard Windows XP keyboard layouts or is it some third party oftware? 5. Do you have some additional keyboard related software? For example I have Logitech iTouch installed. 6. How many times on average you have to repeat the layout switch to see the problem? I have one idea about one patch that was originally written for Win98 bug 331752, but never found it's way in tree because Win9x support was removed. Patch https://bugzilla.mozilla.org/attachment.cgi?id=216998 may actually help. Is anyone able/willing to build their own version (Martijn)? If not I can create binary version of widget dll for tests.

(In reply to comment #6) > I have trouble to recreate the problem. I tried switching between > Latvian->Russian->Greek->Finnish layouts and it always worked as expected. > > Can you post more details how you recreate the problem? > 1. Are you pressing Alt first and then Shift or vice versa? Maybe both almost > immediately? I always press ALT first. > 2. How fast do you type? Dunno... 3-4 letters in second maybe. > 3. Is CapsLock somehow involved? No. > 4. Are these standard Windows XP keyboard layouts or is it some third party > oftware? Standard XP layouts. > 5. Do you have some additional keyboard related software? For example I have > Logitech iTouch installed. I have Microsoft IntelliType Pro (with Microsoft Internet Keyboard). > 6. How many times on average you have to repeat the layout switch to see the > problem? Around 6-7 times. I also found it easily to reproduce when you shange layout 2 times really fast (without typing anything). That was response about sticky ALT, sticky SHIFT almost always happens. Is there separate bug for it?

(In reply to comment #6) > 1. Are you pressing Alt first and then Shift or vice versa? Maybe both almost > immediately? It doesn't make any difference > 2. How fast do you type? Irrelevant, too. I would answer "at a normal speed" > 3. Is CapsLock somehow involved? What do you mean? It's not involved on purpose > 4. Are these standard Windows XP keyboard layouts or is it some third party > oftware? standard > 5. Do you have some additional keyboard related software? For example I have > Logitech iTouch installed. nop! > 6. How many times on average you have to repeat the layout switch to see the > problem? Till two days builds ago, just once. In the most recent two nightlies, it takes two switches; see below: english layout, focus on minefield english works OK switch to greek (left alt shift), greek works OK switch to english (left alt shift), english works OK switch to greek (left alt shift) -> Shift key becomes Sticky in minefield, and all other applications (except MS-Office).

(In reply to comment #6) > 1. Are you pressing Alt first and then Shift or vice versa? Maybe both almost > immediately? Slam both with thumb and little finger - I'm pretty sure I hit Alt first. NOTE: Did a little testing, the key that's pressed first will stick. > 2. How fast do you type? Irrelevant, the key sticks no matter what. > 3. Is CapsLock somehow involved? No. > 4. Are these standard Windows XP keyboard layouts or is it some third party > oftware? Standard. > 5. Do you have some additional keyboard related software? For example I have > Logitech iTouch installed. No. > 6. How many times on average you have to repeat the layout switch to see the > problem? One - happens every time I switch from English to Finnish, never the other way around.

I still was not able to reproduce it on my Firefox debug build on desktop machine, but I see the problem with Minefield nightly build on my notebook. Will check if patch 216998 fixes the problem.

Now I can recreate it with on development machine on static optimized build, but not on debug non-optimized. Seems to be some timing related problem. Will see if repeatable on debug optimized build. The patch from bug 331752 does not help.

I can see problem only on the retail builds and not on debug ones. It does not matter whether it is optimized or non-optimized. Seems that problem is in the use of ::BlockInput() function which is called only in non-debug case. Sometimes it misses the WM_KEYUP (VK_MENU) message and keeps thinking that ALT button is still pressed. Probably it is safe to not call this function even in retail code.

As this was always working fine in debug builds where ::BlockInput was never called (to make sure that mouse and keyboard work in debugger in single step mode), I think it is safe to remove these calls even in retail version. When I initially wrote the code it seemed that these will add extra safety, but if I understand things right even if user presses some keys while in KeyboardLayout::LoadLayout() it should not affect anything as events are put in queue. I also added the ::GetKeyboardState (originalKbdState) / ::SetKeyboardState (originalKbdState) to preserve and later restore the keyboard state that was active on the KeyboardLayout::LoadLayout(). It was required for Win9x (see bug 331752). On Win2k and later it does not seem to change anything, but still I think it is better to have these calls.

The bug is still alive in nightly builds... :-(

Of course it is still alive - the patch is not yet checked into the source tree. Ere, Vladimir. Who should superreview this? I can ask roc, but probably you can suggest someone else. Also feel free to checkin the patch. Thanks

mozilla/widget/src/windows/nsKeyboardLayout.cpp 3.11