GNOME Bugzilla – Bug 324480
Selecting first item with keyboard is difficult
Last modified: 2006-05-28 23:35:14 UTC
Please describe the problem: Steps to reproduce: 1. Open a folder (in browse mode) 2. Press the down arrow key 3. Notice that the accessibility focus is on the first item (outline around the row), but not the selection (highlighted row). 4. Press the down arrow key again. 5. Now the second item is selected. 6. Press the up arrow key again. 7. Now the first item is finally selected, but I expected this at 3. Actual results: Expected results: Does this happen every time? Other information: This was discussed/improved slightly in this (hard to follow) bug, which made it possible to select a single item with two down arrow presses: http://bugzilla.gnome.org/show_bug.cgi?id=131226
Murray, I believe this is a dup of 131226 in fact. At least, IMO the patch for 131226 is the correct fix for this problem, as it : 1) makes it possible to navigate to the list (including a list containing only one item) without selecting it; and 2) makes the selection of the first item in a list consistent with selecting other items in a list. Bill
> I believe this is a dup of 131226 But that bug is closed, and I am using the latest stuff. > 1) makes it possible to navigate to the list This is not about making it possible. (That is done and I am grateful.) This is about making is not strange. > makes the selection of the first item in a list consistent with selecting other items in a list. It's strange in both cases, because of step 3. above.
Murray: Ah, then some patch didn't get applied (maybe this is a dup of a _different_ bug), since we (Sun) are using a patch which causes selection of the FIRST item to occur at step 5 (rather than selection of the _second_ item). If selection of the first item occurred at step 3, there would be no way to keyboard navigate through/past a list without causing a selection to occur, which is not desirable.
Created attachment 56153 [details] [review] patch to provide described keynav behavior for treeviews patch may require some tweaking to apply to HEAD, as it's a gnome-2.6 patch.
> If selection of the first item occurred at step 3, there would be no way to > keyboard navigate through/past a list without causing a selection to occur, > which is not desirable. Maybe it's desirable for treeviews in which changes of selection have no great effect, which would be most of them. I guess you do this lots, but could we have a quick example?
File choosers are an example where making a selection matters, and also the theme capplet is a prime example. There are lots of others but I can't think of them offhand - I only recall LOTS of gnopernicus problem reports that turned out to be keynav issues in the treeview, because blind users doing tab navigation were selecting stuff that shouldn't be selected.
Ah, I guess the problem is that, for instance, blind users move the accessibility focus just to see what's there, but subsequent operations would be affected by an inadvertent selection if they did that while also automatically changing the selection. Wow. I've just noticed that the accessibility focus thing doesn't even appear when accessibility support is turned off. That's nifty.
Really? What "focus thing" ? It shouldn't change depending on the "accessibility" key, that key is actually for "assistive technology support" and is not needed by keynav-only user who aren't using a screenreader. If you're right, then that's another bug.
(On Ubuntu Dapper), - with accessibility support turned on: a down arrow in a Nautilus window moves the accessibility outline focus thing moves to the first item and a second down causes the second item to be highlighted, as described. - with accessibility supported turned off: a down arrow in a Nautilus window highlights the first selection. Ctrl-Arrow can still be used to move the accessibility outline focus thing.
Note that a re-login is necessary to change the behaviour, so it's not just checking a gconf key.
Murray, what you are talking about is called the "cursor" in treeview terminology.
Hi Matthias: I think both behaviors reported by Murray are wrong, in different ways. I also think that the behavior should not change noticeably when the assistive technology gconf keys (aka the 'accessibility' key) is toggled. While in some cases it may seen more convenient to "select on focus", I think consistency arguments win the day in favor of making the treeview not select on focus, but only select on subsequent arrow key presses.
I am not seeing that dependency on a11y being turned on. That must be some Ubuntu patch if it is the case. I'll ask jrb what he thinks about the change proposed in #4
> I am not seeing that dependency on a11y being turned on. > That must be some Ubuntu patch if it is the case. I don't see it now either. I swear it was so. It must have been some temporary bug solved by an update. So, this bug is just about the patch in #4.
*** Bug 303669 has been marked as a duplicate of this bug. ***
Reworked the patch, also the shift key will start at the current focus row now. Committed to HEAD.