GNOME Bugzilla – Bug 163791
Table lines in Search Results not read properly
Last modified: 2005-01-13 16:19:53 UTC
Using gnopernicus 0.9.17 and gnome-search-tool 2.6.2 - Activate gnopernicus and enable speech. - From the main menu, go to "Find Files..." - Enter a '*' into the "Name contains" combobox and press <Return> - Press <tab> six times and focus is on the first entry of the search results table. Notice that "table search results" is spoken but not the name of the file or the location. The first line is only focused, not highlighted. - Press <down> and focus goes to the second line. This time the name and location are spoken and the line also becomes highlighted. So, in order for the first table line to be read, the user has to press <down> and then <up>. - Enter name into the "Name contains" combobox that will only produce one result and press <Return>. - Press <tab> six times to focus on the single search result. "Table Search Resuls" is spoken as before. In this case the user must press <right> and then <left> to hear the location of the file followed by its name. These should be spoken automatically when the table line is focused.
When focus moves to "Search Results" table from another widget, there is no cell in the current selected line with SPI_STATE_FOCUSED. Without a SPI_STATE_FOCUSED cell gnopernicus can not decide which one is the current cell in the table. We are looking (in gnopernicus) for the selection inside a table. If there is a selection, we are looking for the cell which has SPI_STATE_FOCUSED - this will be the current cell. In this way we decide, if there is a multicolumn table,which one is the current cell.
*** This bug has been marked as a duplicate of 159561 ***
Dana - you marked this as a dup of 'notabug'. But from the user perspective it IS a bug. Reopening defect. If the app behavior is WRONG, then the bug is in the app; if gnopernicus just can't handle this situation, then the bug is still valid, but is in gnopernicus.
*** Bug 163696 has been marked as a duplicate of this bug. ***
Is true that gnopernicus (in the current implementation) can't handle the situation when a table doesn't have a SPI_STATE_FOCUSED cell. As a fix for this problem, we can implement following logic: if there is no cell having SPI_STATE_FOCUSED, then we can consider as the current cell the first selected cell which is VISIBLE and SHOWING. But there is a problem with this table: AccessibleSelection_getNSelectedChildren returns 0, so we really can not propose a 'current cell'. There is no FOCUSED or SELECTED cell in this table. I believe this is an application bug.
agreed that this is an application bug or possibly a gail bug.
Bug #163946 was filed for the problem described in comment #5.
Bug #163949 was filed against gnopernicus to describe the problem with the lack of SPI_STATE_FOCUSED. *** This bug has been marked as a duplicate of 163949 ***