GNOME Bugzilla – Bug 109798
metacity keybinding issues with ATs and StickyKeys
Last modified: 2005-08-16 17:41:18 UTC
[Ctrl]-Alt-Tab doesn't really work too well in conjunction with StickyKeys. With SK turned on, if you press Alt, then Tab (or Ctrl, then Alt, then Tab): - you don't get the popup window list, focus just switches immediately to the next panel/window... (so you also don't get the 'thick black' focus indicator like you would if you had StickyKeys turned off) - with SK turned on, there's no equivalent to pressing Alt-Tab, then just repeatedly tapping Tab with Alt still held down. You have to press all two or three keys in succession each time. (Alt then Tab, Alt then Tab, Alt then Tab). It would be better if, with SK switched on, you could perhaps do something like Alt then Tab to pop up the list, then Tab to move focus along the list, then Enter to confirm the switch. I think Bill also mentioned that ATs don't get any 'window switched' notification until all the keys are released, therefore a blind user (with SK turned off) can't tell which window/panel they've 'stopped' on in the popup list until they let go of Alt-Tab. Perhaps he or Padraig could elaborate here.
Is "use Alt+Esc then" an acceptable answer here? Note that you can bind the Alt+Esc behavior to Alt+Tab if you wanted.
That doesn't help the way Alt+Esc currently works, because if you press Alt then Esc, then press Alt then Esc again, you just get back to the window you started from :) (At least, you do on the 2.2 build I'm running just now...) Even if that did work differently, it presumably wouldn't offer any reduction in keystrokes for an SK user over the Alt-Tab method, although I'm not sure quite how big an issue that is... Bill probably has more thoughts...
Actually I don't have a big problem with the Alt-tab behavior which seems to work now (it was reported to be broken, but I think that was some kind of config problem). The dark lines are missing but I don't think that's a high-priority bug, just an annoyance. The visual feedback issue for panels is more significant since it can be real hard to see focus indication for some panel configurations; in theory it should always be there, but... However there's a significantly more aggravating bug in that Ctrl-Alt-Tab doesn't cycle through panels, on my system (with a foobar and a bottom edge panel) it just goes desktop->edgepanel->desktop->edgepanel, the foobar never gets focussed. It seems that GOK in dwell mode (or any mode, when using XInput and not corepointer) can successfully do the ctrl-alt-Tab thing and the Alt-Tab thing (with reduced visual feedback, as noted).
OK - possibly this should be a separate bug, BUT, there's another troubling behavior I am seeing. It's possible to "lock" a modifier from XKB, and therefore from GOK. This allows you to do Alt-Alt-TabTabTab etc. and get the visual feedback, but... if you lock Alt (sticky keys on, Alt twice) then pressing tab cycles through the windows on the window popup list UNTIL you unlock the Alt key. OK, maybe that's allright, BUT if you try it with GOK in dwell mode you'll get stuck since it seems GOK doesn't get the button-enter notifications during this process. Sigh. metacity seems to be doing some kind of grab during the Alt-down... I can try this with GOK-driven-from-XInput to see if the same problem is evident.
Marking AP2 to reflect a11y team's assessment of a11y impact.
When driving GOK from XInput you can alt-tab through windows by locking the Alt modifier and then unlocking it, i.e. Alt-Alt-Tab-[Tab]-[Tab]...-Alt Ctrl-Alt-Tab seems to work with Sticky Keys now, though the lack of the focus lines is a more serious problem there. Ctrl-Ctrl-Alt-Alt-Tab does show the focus lines though - but what a pain in the backside! I suggest that the focus lines should be drawn when the TAB key is down (e.g. cleared when the Tab key release is received) as well as when Ctrl and Alt are active - in this way a sticky keys user would get visual feedback without having to lock the modifiers. What do you think Havoc, what about keeping the focus visuals onscreen until Tab-release?
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
I think I've totally lost track of what this bug is about. ;-) It seems like there are a number of issues mentioned, and I'm not sure I understand the explanations properly (probably I need to sit down and try it out). Can someone try to summarize the outstanding issues?
For starters, there appear to be several sets of issues: (1) keynav interactions/conflicts with AccessX/StickyKeys itself; (2) conflicts with GOK due to metacity key grabs (active grab during cycle); (3) problems with onscreen focus indication during window nav; (4) missing/inadequate notification for AT clients like gnopernicus when cycling through windows; (5) broken navigation under some conditions while using AT or AccessX. Some of these might be fixed now, so I/we need to check each against the original report to see which ones seem to be live. Here are my initial assessments: [Issue #1] I _think_ that #1 is mostly an annoyance now, but annoying enough to consider fixing (StickyKeys equivalent of hold-down-a-key requires lock (2 keypresses per modifier) followed by unlock (1 keypress per modifier) bracketing the navigation. Thus keynav to a panel requires at least Alt-Alt-Ctrl-Ctrl-TAB-Alt-Ctrl = 7 keystrokes and window keynav requires Alt-Alt-TAB-[TAB]?-Alt. [Issue #5] Note also that "Alt-TAB; Alt-TAB; Alt-TAB" (i.e. sequential Alt-TAB presses) do not cycle focus through all the windows, that only works for successive TAB presses during a single Alt-Down. This is an aspect of issue #5 above. Issue #1 makes this issue more important since in many cases it may be more convenient for a user to use the 'latched not locked' method. I don't know if there are conflicts with gnopernicus at this time; I think that as long as GOK is not using the core pointer as its driving device, GOK can be used (laboriously!) to perform the above keynav. There are definite conflicts with GOK when corepointer is used, see issue #2. [Issue #4] This is addressed by bug #120025. [Issue #3] This appears to be fixed or at least "looks OK to me" on my system at the moment. [Issue #2] The fact that an active grab is in operation during the whole 'keynav cycle' can be a problem; it definitely breaks GOK in core-pointer mode, and conflicts with gnopernicus controls. However I think there are some 'workarounds' (i.e. don't try to control gnopernicus while switching windows, don't use GOK in corepointer mode with window keynav). A fix for #4 will reduce the need to interact with gnopernicus during the keynav. However if we can think of an alternative keynav mechanism it would be worth considering, i.e. make the Alt-grab method with pre-focus visual optional, with an alternative keynav technique that's more of a "traditional" grab on Alt-TAB. A fix for Issue #5 would be required for this to work correctly of course. Havoc, I could split these bugs out if you prefer and make this a dependent on them. But in summary, the urgent issues not captured/addressed by other bugs: #5 (Alt-TAB + Alt-TAB doesn't cycle correctly) - fixing this would reduce the severity of other issues because it would give an alternative to locking modifiers with StickyKeys, it would give gnopernicus users an alternative that gave them output on a per-window basis during focus-cycling, it would reduce the active-grab duration issues, and allow keynav with GOK in corepointer mode. If I find that any of the other issues are still problems I will amend this report.
Changing summary to reflect issue #5 then, and let's put any other issues still open on new bugs. If the summary isn't right please correct it. Making Alt+Tab followed by a new Alt+Tab go forward twice seems to break the expected behavior that Windows and other systems have had for years, if I understand it correctly. I don't think we can do that by default for Alt+Tab. Many people expect to be able to toggle between two windows by hitting Alt+Tab or Alt+Esc repeatedly. So I guess we'd have to add a new binding in gconf. But this binding would need to be defined. Currently the tab order is most-recently-used which produces the behavior that alt+tab twice in a row goes back to the previous window. The tab order with the new binding would be just some fixed order I suppose, perhaps order in which the window was mapped. That could be useful anyway I guess - metacity originally used order-of-map rather than MRU on the grounds that users don't understand MRU and that it could match the window list. Though the window list doesn't use order of map, and probably should.
Havoc: Changing summary back; I don't think that we can deal with the original topic of this bug via 'Issue #5' if it's not the behavior for the default keybinding. So the importance of Issues #1 and #2 are correspondingly higher. The Alt-TAB + Alt-TAB back-and-forth behavior may be normal for Windows but I don't think it matches behaviors of CDE. Let's confirm that we can't make Alt-TAB cycle forward always (with Alt-ESC going backwards, etc.) I don't see a compelling need for 'toggle' behavior with Alt-TAB when we have (admittedly more awkward) Alt-Shift-TAB to do that. Your conclusions are a surprise to me.
You're confusing me again; I thought you said #5 was the only important issue not covered by other bugs. The right course of action may be to just open a new bug for each issue and set any dependencies that make sense. ;-) Changing Alt+Tab not to be MRU is out of the question IMO. Metacity originally had non-MRU Alt+Tab and it generated a _lot_ of complaints because people are simply used to using it for toggling between two windows. MRU is the expected behavior of Alt+Tab I think.
being as different as possible from CDE is a good goal for us to have. Cause... damn. I mean, really.
The user expectation here seems to be from Windows and other Linux WMs/desktops.
should we turn this into an RFE for metacity-order-of-map keybinding or config option? i.e. either [x] metacity uses MRU or optional metacity next-in-order-of-map command to which a keycomb could be bound (obviously we need a better user-visible string than 'MRU' ;-)
For issue #5 at least, rather than adding a user preference, couldn't we just alter the behaviour of Alt-Tab depending on whether sticky keys was turned on or not? I.e. if StickyKeys is off, Alt-Tab, Alt-Tab takes you back to where you started as it does now, and if it's on, Alt-Tab, Alt-Tab does the same as Alt-Tab, Tab.
See bug 102656, which seems to be about mostly the same thing, though perhaps just a subset (the "sticky alt-tab popup" stuff, and comparison to Windows).
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Re-reading, I can't see the difference between this bug and bug 102656. Perhaps one could see the difference by looking at all 5 issues listed in comment 9, but it looked like we were concentrating on just one aspect (and besides, Havoc requested other bugs to be filed separately if we want to look at more issues and 102656 seems to have covered more than one of the issues here anyway). Let me know if there really is something different that this bug is about. *** This bug has been marked as a duplicate of 102656 ***