GNOME Bugzilla – Bug 707799
MessageTrayMenuButton is not key-navigable
Last modified: 2014-09-17 04:58:49 UTC
STEPS TO REPRODUCE IT 1. Open message tray using the ctrl+alt+tab switcher 1.1 Focus is placed on one of the message tray notifications 2. Navigate using keyboard arrows or tab EXPECTED OUTCOME MessageTrayMenuButton (that button at the top left of the message tray bar) is navigable, getting the focus. ACTUAL OUTCOME MessageTrayMenuButton is only navigable is you don't have any notification at the bar. In that case when the tray is open, no element is focused, and you need to press tab in order to focus on that button. NOTES Intuitively, I was expecting that new button to be included on the same focus chain that the notification buttons. After a quick look on the code, that doesn't happen as the button is not included on the same container that those buttons (that are placed at MessageTray._summary). At this moment I think that the easier solution would be tweak the key navigation while navigating on the notification items (sources), in order to include the MessageTrayMenuButton. Probably something similar to PopupSubMenuMenuItem._onKeyPressEvent.
This would be nice to fix in order to not regress on accessibility.
Created attachment 254871 [details] [review] util: Move FocusTrap from ViewSelector It is generally useful for focus shenanigans, so move it to a more neutral place.
Created attachment 254872 [details] [review] messageTray: Add focusTrap The summary container will trap the focus if any sources are present, making the message tray menu unreachable by keynav. Apply the same hack as in searchDisplay and add a focusTrap to move the focus manually as necessary.
Created attachment 254873 [details] [review] messageTray: Improve :focus style of tray menu button Rather than just changing the icon color, we should use the same focus indication as for summary buttons.
The patches are not the prettiest, but they work. Now, I'm not sure it's worth to include this to be honest - it fixes reaching the tray menu button by keynav, but from there we have the same problem as in but 684452, e.g. the menu is not focused (making it pretty useless) ...
(In reply to comment #5) > The patches are not the prettiest, but they work. Now, I'm not sure it's worth > to include this to be honest - it fixes reaching the tray menu button by > keynav, but from there we have the same problem as in but 684452, e.g. the menu > is not focused (making it pretty useless) ... Now that you point bug 684452, I think that bug 707800 is a duplicate. Could you confirm that? And in relation to "I'm not sure it's worth ..." (In reply to comment #1) > This would be nice to fix in order to not regress on accessibility. Well, technically this is not a regression but a accessibity support delay, as that button was not available on 3.8. Although having it not accessible is unfortunate, taking into account the amount of patches on this bug, the amount of patches on on bug 684452 (that for me is surprising, as the context menu on the dash works fine) and how late we are in the cycle, not sure if we should postpone this to 3.12
ok, moving this off the 3.10 list - we can reconsider for 3.10.1
(In reply to comment #5) > but we have the same problem as in but 684452, e.g. the menu > is not focused (making it pretty useless) ... This was fixed in bug 735614, so let's get another keynav issue off the list - as the message tray will most likely be removed next cycle, I don't think it's worth shifting code around, so just re-using FocusTrap directly from ViewSelector now ... Attachment 254872 [details] pushed as 5623f3b - messageTray: Add focusTrap