GNOME Bugzilla – Bug 166553
There is no initially cell in 'Files' table having SPI_STATE_SELECTED
Last modified: 2018-04-15 00:31:15 UTC
1. Open gedit 2. Try to open a existing document; the 'Open File' window appears. 3. Navigate using tab to the 'Files' table. 4. There is no SPI_STATE_SELECTED cell in this table. Without a SPI_STATE_SELECTED cell, gnopernicus can not report the current table line. This bug is present starting with Cinnabar 26.
gedit is using the standard gtk+ file selector dialog. Changing product to gtk+
Alexandra, which version of gtk+ you are using ?
I am using the default version of gtk2 (version 2.4.14-26) installed with Cinnabar 26.
Matthias, if you can point us to a patch for a later version, we can look into a backport. We'll need it for our product line at least. Thanks!
Federico would be the one to ask, not sure if he kept updating the gtk-2-4 branch for filechooser changes
In 2.6.2, the file chooser definitively has a (visually) selected row when it comes up in OPEN mode. Can SPI_STATE_SELECTED diverge from the visual selection ?
Matthias: SPI_STATE_SELECTED should be consistent with the visual selection. Maybe this was fixed post 2.4?
I have a bunch of pending backports from 2.6 to 2.4. I'll need to do them for Novell Linux Desktop 9, anyway. In the meantime, you may want to see the patches in these SRPMS: http://primates.ximian.com/~federico/misc/gtk+/SRPMS/
Note that this change in 2.6 is probably cause of bug 166836, which broke SELECT_FOLDER functionality very badly (to the point of being near unusable)
Maciej: this bug is still correct however, i.e. there must be SPI_STATE_SELECTED consistent with all visual selections. Perhaps your complaint is that the file selector always has a selection when it's initially posted, in 2.6? That would be a different bug, actually. Also, if that behavior were changed, we'd need API in the file selector to indicate whether it was posted with an initial selection or not, I think.
I had a look at the bug and evaluated it. I feel the issue is in GtkTreeView not in GtkFileSelector. The problem described can be seen from other applications also, where treeview is used. a) Nautilus - Open a folder with some files in Browser mode, then select list view. Now, using Tab, give focus to the treeview. The first file/folder's name will not be read by gnopernicus. b) gnome-search-tool: Search for a file/folder and when it lists the results, press Tab to give focus to the 'search results' treeview. The first result is not read by gnopernicus. In both the cases, the first row is just highlighted but not selected. Please give your advice if the above evaluation is correct. If so, I will work towards fixing it in treeview. Refer to bug#131226, which fixes a similar issue in treeview.
It's OK for the first element not to be SELECTED in the file selector case, as it is ACTIVE instead. i.e. since the first element is NOT highlighted, but only has a focus indication around it, it should not have the state selected. In the nautilus case, it's pretty much the same - the first element in the table has not been selected, and so the lack of SELECTED state is correct. However, in the case of 'File->Open' from gedit, the first element IS selected visually, therefore the SELECTED state should be true.
Bill, thanks for the input. Considering gsearchtool and nautilus, the premise in bug #131226 for not SELECTING the row and just drawing the focus when tabbing in to the treeview was that we might select the wrong row when we return to the treeview. "it was deemed important to be able to tab to a TreeView without altering the selection" - Jonathan But I suspect that we could fix taking care of what JRB was pointing to. So, when the user tabs in or uses arrow key to get in to the treeview, a) initially if there was no selection, select the first row. b) if there was a previous selection, retain it. Guess the GtkFileChooser behaviour reported in #166836 and #162358 need to be fixed in that widget but the basic GtkTreeView behaviour should be as above.
Created attachment 45126 [details] [review] proposed patch
Srirama: not sure behavior (a) in #13 above is correct in the general case. If there is NO selection, I agree with jonathan that tabbing should not create one. The file chooser issue is another matter; if a widget 'acts' as though there is a selection, behaviorally, then that selection should be shown visually and also explicitly reported via ATK_STATE_SELECTED. But if the widget's behavior does not imply a selection initially, we shouldn't force one.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Apologies for spam... marking as AP3 to reflect accessibility impact.
For what I can tell this was a bug that affected gtk 2.4 but was fixed in 2.6. Since its 7 years later I assume this bug is obsolete?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new