GNOME Bugzilla – Bug 710144
NMWirelessDialog: not possible to connect to a network using only keyboard
Last modified: 2013-10-17 17:48:33 UTC
STEPS TO REPRODUCE: 1. Navigate using the keyboard through the panel 2. Click on Select Network 2.1 A list of available Wi-Fi appear 3. Navigate through the list of networks EXPECTED OUTCOME: Being able to connect to one of the networks using only keyboard. ACTUAL OUTCOME: Pressing space or return (usual keys to activate items) doesn't work. In the same way, you can't jump to the connect button without changing the selection. Usually on Gtk+ TAB is used to change the container, but on gnome-shell it only changes the container when it arrives to the last item (behaviour that we should change).
Created attachment 257307 [details] [review] Being able to connect using only keyboard Changing the behaviour (using TABS to change the container) is too complex, as ideally I would like this included on 3.10.1. So this patch just connect to the wi-fi if the user press the usual enter/space keys. Something that makes sense even if we get a way to move to the Connect button without changing the selection.
Review of attachment 257307 [details] [review]: Pity that the dialog breaks the default-action handling, but the workaround could be a lot simpler (e.g. without an additional signal): ::: js/ui/status/network.js @@ +985,3 @@ this._selectNetwork(network); })); + network.item.connect('connect', Lang.bind(this, function() { network.item.actor.connect('clicked', ...)
Created attachment 257347 [details] [review] Fixes the bug by adding a callback to clicked signal as suggested on previous review Thanks for the quick review. Patch updated following review on comment 2. BTW, I'm right now in a coffee shop at Montreal, and in one hour will take a flight. So if the patch is ok (and hopefully ok to be included in 3.10.1) I would be really grateful if the patch is committed without waiting for me.
Looking at the master branch, this bug was solved. And also included on the 3.10.1 release. Thanks! But, it seems that the patch pushed was the old one (the one reviewed as need-works). So, what I should do? Wait for a review of the new patch and override the previous one? Just close the bug?
Created attachment 257567 [details] [review] Revert "network: being able to use keyboard to connect to a Wireless" This reverts commit d175a588f7949272e6a69bb956b6497a0b6897b0.
Created attachment 257568 [details] [review] network: Don't use StButtons for items in selector Their use blocks activation of the default button by keyboard, which is important for accessibility. Use a Clutter.ClickAction instead, which doesn't have this problem as it only considers mouse events.
(In reply to comment #4) > But, it seems that the patch pushed was the old one (the one reviewed as > need-works). Yeah, I was a bit quick in my review, sorry - you can't just use a plain 'clicked' handler, you'd still need to filter for keyboard events only to not change the behavior for mouse clicks (e.g. in that case an item should only be selected and we require an explicit click on the connect button). It was getting late for the release, so I didn't look into fixing this differently, and just went with the first version which works. In case we still want a nicer fix, here's an alternative approach ...
Review of attachment 257567 [details] [review]: This was already pushed.
Review of attachment 257568 [details] [review]: OK. ::: js/ui/status/network.js @@ +956,3 @@ _selectNetwork: function(network) { if (this._selectedNetwork) + this._selectedNetwork.item.actor.remove_style_pseudo_class('checked'); I was sort of using 'checked' as a hack. I'd rather see 'selected'.
Attachment 257567 [details] pushed as 2f39f3d - Revert "network: being able to use keyboard to connect to a Wireless" Attachment 257568 [details] pushed as af1f9cd - network: Don't use StButtons for items in selector Pushed with s/checked/selected/ as suggested.