GNOME Bugzilla – Bug 548169
Orca key gets stuck on
Last modified: 2008-08-28 14:16:46 UTC
Please describe the problem: When using orca if the orca key is pressed it seems to get stuck on. Steps to reproduce: Run orca, press the orca key. press a key which orca uses but normally requires the orca key as well to give an orca command eg. press h. Actual results: When the h is pressed orca enters learn mode Expected results: Orca should pass the h keypress pass through to the application with focus. Does this happen every time? Mostly. Other information: Originally tried it with gail, at-spi and atk rom gnome desktop 2.22, but upgraded to svn trunk to see if that would resolve it but it hasn't. h was only example other keys behave as if orca key is held down (I have needed to use backspace to get bypass mode to write letters such as "hsq fb",etc in this report).
Can you explain the behavior more and which application(s) you are using that exhibit this behavior? In particular, is this isolated to Firefox and/or Thunderbird? Which key do you have defined as the Orca key (e.g., Caps Lock, Insert, etc.)?
I have done more to investigate how this bug is showing itself, and here is the information: I have more than one account in use on this machine, and doing about 3 or 4 logins on each it indicates that it is account specific (always showed on one account, never shown on the other). The orca key is set to insert (I am using the numpad 0/numpad insert). The following is only for the account which is showing this bug: This problem shows itself from any application (I have tried evolution, nautilus (at the desktop) and firefox). It appears also as if the orca key bindings aren't loaded properly, as the number pad keys for flat review don't seem to work (certainly for before I press the orca key, and I think for after pressing the orca key). After the orca key is pressed if the bug shows itself (its always showing itself on first press of orca key if it is going to show itself) then the key board behaves as if the orca key is held down. I don't know how this shows itself to the application if backspace is pressed to achieve bypass mode (that was the only way I could type the letter "h" when submitting the original report). Once in the state of the orca key appearing to be stuck on, this seems to stay so even if I restart orca, it appears to require a logout to reset the orca key state. (In reply to comment #1) > Can you explain the behavior more and which application(s) you are using that > exhibit this behavior? In particular, is this isolated to Firefox and/or > Thunderbird? Which key do you have defined as the Orca key (e.g., Caps Lock, > Insert, etc.)? >
(In reply to comment #2) > I have more than one account in use on this machine, and doing about 3 or 4 > logins on each it indicates that it is account specific (always showed on one > account, never shown on the other). Very strange. In the offending account, can you please tar up your ~/.orca directory, rm -rf your ~/.orca directory and then retry to see if the problem disappears? If so, please post your tarball as an attachment to this bug so we can take a look at it for oddities. If not, can you please try pressing the NumLock key to see if that has any effect?
Created attachment 116864 [details] ~/.orca directory Tried the suggestions and got the following results: after removing the ~/.orca directory the bug still seemed to be present (I may have noticed another bug at the same time, but unsure if it is related, orca wasn't loading new setting I made in orca settings dialog when pressing apply or OK). Initial report was based on numlock being off (light on keyboard was off). Bug still seems to be present when turning numlock on (either before or after pressing orca key). When altering numlock state before pressing orca key (IE immediately after orca loads) numlock state change (also capslock) is not announced by orca (although set to) but once orca key is pressed lock keys changes are spoken as normal. For what it is worth I have attached ~/.orca directory.
(In reply to comment #4) > Created an attachment (id=116864) [edit] > ~/.orca directory > after removing the ~/.orca directory the bug still seemed to be present OK - this makes it seem as though something is going awry with the user environment. I'm not sure what it could be, though. Are you on a laptop or a desktop? In addition, please run "xmodmap -pke" in both an account that doesn't exhibit this behavior and in an account the does exhibit this behvaior. I wonder if something might be mucked with the keymap?
I have tried running xmodmap -pke and redirected the output to file. when using diff to compare the two files (diff -s xmodmap_output xmodmap_output_bug) it reports the files are identical. Shall I still post these xmodmap output files?
> I have tried running xmodmap -pke and redirected the output to file. when using > diff to compare the two files (diff -s xmodmap_output xmodmap_output_bug) it > reports the files are identical. Shall I still post these xmodmap output files? No need to post. Darn. OK. So, next thing to try (I have a feeling this is going to be very hard to diagnose without me sitting directly behind your machine) turn on Orca full debugging, restart orca, reproduce the problem, then quit Orca and post the debug file. Info on debugging can be found here: http://live.gnome.org/Orca/Debugging.
Created attachment 116937 [details] Orca debug output This attachment is the orca debug output for the following actions: start gnome (orca is set to load automatically), press of "h" to show that orca key is not active, press the numpad insert (orca key, this is a press and it is released immediately), press "h" (orca enters learn mode in this affected account), press escape, then go through the menus to logout of gnome. This is being performed on a desktop system with orca's desktop keymap. An interesting thing is that when orca key is pressed in the affected account in the run above, the desktop gets focus.
(In reply to comment #8) > Created an attachment (id=116937) [edit] > Orca debug output Thanks! What I'm seeing in this output is that Orca it contains a release of the KP_Insert key, but no press. Very strange. Can you try another test (with debugging on) where you do nothing except just press and release the KP_Insert key twice after Orca starts?
Created attachment 116963 [details] Debug output for two presses of insert key This attachment is for a run where I start gnome and press numpad insert twice. After that there is just the logout of gnome stuff.
(In reply to comment #10) > Created an attachment (id=116963) [edit] > Debug output for two presses of insert key > > This attachment is for a run where I start gnome and press numpad insert twice. > After that there is just the logout of gnome stuff. Thanks! This helps some. Does this particular account differ from all the others you have set up in that it's desktop is intially empty? BTW, I'm also seeing a button 1 press in there. Are you pressing the mouse button as well?
Created attachment 116969 [details] Orca debug output for working account This is the output for a working account on my machine when starting gnome and pressing numpad insert twice and exiting gnome.
(In reply to comment #12) > Created an attachment (id=116969) [edit] > Orca debug output for working account > > This is the output for a working account on my machine when starting gnome and > pressing numpad insert twice and exiting gnome. Darn - I don't see any KP_Insert's in the file. Very odd. I'm going to guess that the desktop is coming up empty and nothing has focus until you force something to happen (e.g., Alt+F1). If this is the case, the AT-SPI infrastructure won't kick in until something gets focus, and Orca will not get keyboard events until that time. Can you try configuring your system so *something* automatically starts and appears on the desktop? For example, a gnome-terminal?
Created attachment 116974 [details] Output from account showing bug with gnome-terminal loading at start Here is an updated version of the orca run for two presses of insert on numpad with gnome-terminal loading at start up. Only difference is that I press alt+f4 after doing the two insert presses to clear the gnome-terminal window before logging out.
Created attachment 116975 [details] Orca output for working account with gnome-terminal loading at start up This is the updated output from orca running in a working account with gnome-terminal starting at start up. Key presses are the two numpad insert and then keys to exit gnome.
This is indeed still very strange. Is it possible you set up some sort of custom GNOME keybindings for the offending account? Alternatively, I wonder if some sort of error message is coming up in the offending account and Orca is failing to read it. Do you have someone that can observe the screen as you login into the account that exhibits this behavior and as you login to an account that doesn't exhibit this behavior?
I believe I have found the cause, and depending on your view may be this should be closed. The cause was I had turned on the keyboard setting for mouse keys, "allow to move pointer from keyboard" (I think that is the exact label of the check box). Either this should be noted in documentation, or better still may be orca could check for this on start up and warn if its enabled (eg. a message such as "It appears that you have enabled mouse keys, this can cause problems with orca. Would you like Orca to disable mouse keys? Yes No"). I leave the exact solution to you, but to me the latter would be better as it actively warns the user rather than expect they have taken everything in from the documentation. (In reply to comment #16) > This is indeed still very strange. Is it possible you set up some sort of > custom GNOME keybindings for the offending account? Alternatively, I wonder if > some sort of error message is coming up in the offending account and Orca is > failing to read it. > > Do you have someone that can observe the screen as you login into the account > that exhibits this behavior and as you login to an account that doesn't exhibit > this behavior? >
I forgot to ask, can others reproduce the behaviour I originally described if enabling this option?
Yee Haa! Thanks for finding this Mike. I can now reproduce this, and I've added a WARNING section to http://live.gnome.org/Orca/KeyboardCommands for now. There might be an XKB API we could dig into from Python, but I'm not quite sure what it is. For now, I'm going to close this bug and we can reinvestigate the warning message idea if someone else runs into the problem. Thanks Mike!