After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 417930 - [Meta] Firefox table mode browsing
[Meta] Firefox table mode browsing
Status: RESOLVED WONTFIX
Product: lsr
Classification: Deprecated
Component: extensions
0.4.x
Other Linux
: Normal normal
: 0.5.4
Assigned To: LSR maintainers
LSR maintainers
gnome[unmaintained]
Depends on: 431349 437757
Blocks: 428979
 
 
Reported: 2007-03-13 17:52 UTC by Peter Parente
Modified: 2011-07-06 06:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Parente 2007-03-13 17:52:16 UTC
When reaching a data table (not layout table) in Firefox, some users find that making the keys behave as they would in an interactive table is more convenient than the linear key definition. For instance, in table mode, up/down would not mean "previous and next item (cell)", they would mean "cell one row above this one" and "cell one row below." Left and right would take on the meaning "cell one to the left" and "cell one to the right."

Clearly both our linear convenience keys and the table convenience keys cannot be active at the same time. Perhaps an option like "AutoTable" would make the most sense? If the user enables it, the arrow keys take on their table definitions when a table is encountered and return to their normal meaning when the table is exited. If the user keeps it disabled, the arrow keys take on the same meaning they have already.

I can see that leaving a table will be troublesome with the keys in table mode. For instance, what if the user tries to walk straight down a column and out the bottom of the table? Do we stop the user at the edge? If so, how does the user get to the content following the table. Do we allow the user to fall out of the table and into the content? If so, then what if it was an accident and the user wants to get back? Most screen readers solve this problem with explicit modes which the user can enter/leave with a key press. We've been successful avoiding such a mode so far, so let's brainstorm about how to get this working without one.
Comment 1 Scott Haeger 2007-03-16 20:46:45 UTC
This would be a great feature and we nearly have all the pieces in place to do it.  However, I suggest we start small and focus on bug #413934 first.  This should give us the skills needed to tackle this much more difficult feature.
Comment 2 Peter Parente 2007-03-20 23:13:44 UTC
Please hold off on this now. There are more critical bugs to tackle first like the one noted in comment #1.
Comment 3 Peter Parente 2007-03-20 23:15:38 UTC
Noting questions from Scott for future reference.

1.  Right now I am trying to handle 'table' items separately from
everything else in ConvReviewKeys so I can utilize the table adapter
functions.   How do I maintain the task_por to the 'table' while still
emulating or calling the review functions? If emulating, what about
chained tasks that update Braille, Mag?  What I am really looking for
here is a strategy to use the table adapters from with the Firefox
review process.  Any insight would be appreciated.

2.  The table adapter navigation and info classes have different when()
methods.  Is this correct?  Should the nav when() be 'loosened' up?
Firefox tables do not provide STATE_MANAGES_DESCENDANTS.
Comment 4 Akhil Laddha 2011-07-06 06:41:55 UTC
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.