Topic Odd behaviour of shift key

Hi,

this may be a side effect of the recently added option to reset modifier keys before output, which had been prompted by Keyman input problems in combination with Firefox.

What happens is this: With this option ticked in Keyman configuration, the shift key starts behaving very erratically. It just behaves as if it was held down all the time, creating not only weird keyboard input, but also weird window behaviour (new browser windows opening automatically when links are clicked, and so forth). I'm not sure whether it is really random, but when I read something in a browser window, and then switch e.g. to Open Office, suddenly everything is all caps, without me as much as touching the shift key.

I don't know exactly what triggers this, but it doesn't happen when Keyman is deactivated, or when the "reset modifier keys ..." option is not set.

I usually notice this weird behaviour with both Firefox and Open Office open, but can't swear that it only occurs when both are opened.

We have reproduced this behaviour on our test systems here and are investigating a resolution. It appears that the shift keys are not always being reset when switching between applications. We aim to get a fix in this week.

I believe that update .183 which is now available for download fixes the issue with the modifier keys.

Unfortunately release .183 didn't fix the problem. Initially I thought so, but now I have the same problems (in Firefox 1.5.0.6). Additionally, for a while it was not possible to hold the shift key and enter more than one character. For instance, I work with Wikis that format headings with several instances of =. I'd hold down the shift key, and the first = would turn out allright, but for the second I'd have to release the shift key and press it again. Oddly this behaviour has just vanished. I have to note that I didn't uninstall the .182 release before installing .183. Could this be the source of the persistence of the problem?

I can't yet reproduce this issue on our test machines; we are continuing to test and will let you know if we find anything. Can you send another diagnostic report to us? We will review it to make sure that nothing else is wrong on your system that could be causing issues.

One other question - are you using any of the Windows accessibility options - StickyKeys or others?

Hi everyone!

I have noticed that this new option of "Reset of modifiers before character output" (Keyman 6.2.183.0) have changed the behaviour of keyboards and WordProcessors in a few issues... It's not critical but strange...

For instance, if I mark this option, 'CapsLock' does not go OK in MSWord 2003 and in OpenOffice 2.0.3: I cannot write Uppercase letters. But if I don't mark the option, OpenOffice cannot use the overstrike method offered by "Combining diacritical marks" signs, which is applied in some keyboards... And when I change between the two moods, it seems Keyman forgets the active Keyboard and I have to select it again...

Thank you anyway for your support. Regards

It sounds like we need to do some more work on this issue - we are currently in a Keyman 7 beta phase which has reduced the amount of time we have to spend on Keyman 6, but I will allocate a day as soon as I can to try and track down and stabilise this feature.

Perhaps this helps: I'm sending another diagnostic report, this time with Firefox 2.0, where the problem persists. This time, however, it's not the shift key that remains activated, but ctrl or alt :-)

Birgit,

I am going to submit a bug report for Firefox - they are misusing the character input messages (WM_CHAR) that Windows uses, and make erroneous assumptions about the state of the keyboard when the WM_CHAR message is received.

I think I have really taken the wrong direction for correcting this issue, assuming that it was a problem with Keyman, rather than examining the way that Firefox processes keystrokes...

Visit
https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=69954#vote_69954
to vote for this bug to be fixed.

In the meantime, I am forced to suggest using alternate browsers (not a great answer, I know). I will research the issue further and investigate creating a patch for Firefox.

I have now created a patch for Firefox that works well in my testing and also improves the stability of Firefox with some Windows keyboards (e.g. Canadian Multilingual).

Again, that patch can be referenced at:
https://bugzilla.mozilla.org/show_bug.cgi?id=69954

Vote for it at:
https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=69954#vote_69954

If you would like to see the patch integrated into a Firefox update, you can discuss this at:
http://forums.mozillazine.org/viewforum.php?f=38
http://www.mozilla.com/en-US/support/
news:mozilla.support.firefox

If you would be keen to get a build of Firefox 3.0a1 that addresses this issue (which is the version I designed the patch for), I will investigate putting it onto our website. It would be better to see if we can get the patch integrated into 2.0.