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 570556 - (ARIA) Treegrid not always navigating or presenting well
(ARIA) Treegrid not always navigating or presenting well
Status: RESOLVED OBSOLETE
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: FUTURE
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
post-3.0
Depends on:
Blocks: 404403
 
 
Reported: 2009-02-04 21:56 UTC by Willie Walker
Modified: 2015-07-22 20:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
new regression test to illustrate the current state of affairs (8.41 KB, patch)
2009-02-15 03:13 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Willie Walker 2009-02-04 21:56:52 UTC
1) Go to http://codetalks.org/source/widgets/treegrid/treegrid.sample.html
2) Problem #1: Tab to "A Question of Love" -- attempt to arrow down.  The focus should change to "Piece of Peace"
3) Problem #2: Press the space key to expand/collapse an item.  Orca doesn't present the new state.

NOTE: these might be separate bugs.
Comment 1 Joanmarie Diggs (IRC: joanie) 2009-02-11 16:38:04 UTC
In both cases, the object which claims focus is the child of the object with the xml-roles. This object has ROLE_UNKNOWN. Since the focused object is not an ARIA widget, our caret navigation can kick in. In addition, since the expanded/collapsed events are issued by the actual ARIA widget rather than the object which claims focus (and hence becomes our locusOfFocus), we ignore them.

Another one I can create ugly hacks for, but this strikes me as not our bug(s).

Will?
Comment 2 Willie Walker 2009-02-11 16:56:24 UTC
(In reply to comment #1)
> In both cases, the object which claims focus is the child of the object with
> the xml-roles. This object has ROLE_UNKNOWN. Since the focused object is not an
> ARIA widget, our caret navigation can kick in. In addition, since the
> expanded/collapsed events are issued by the actual ARIA widget rather than the
> object which claims focus (and hence becomes our locusOfFocus), we ignore them.
> 
> Another one I can create ugly hacks for, but this strikes me as not our bug(s).

Sounds like another thing we need input from the ARIA designers on.  Adding them to the CC list.
Comment 3 Joanmarie Diggs (IRC: joanie) 2009-02-13 23:07:57 UTC
My latest check-in for bug 571058 addresses problem 1. I might be able to create a targeted hack for problem 2, so I'll take this one.
Comment 4 Joanmarie Diggs (IRC: joanie) 2009-02-15 03:13:37 UTC
Created attachment 128747 [details] [review]
new regression test to illustrate the current state of affairs

I've created a new regression test. It illustrates:

1. We are no longer suffering from problem number 1. In fact, given the current ARIA implementation, we're not doing all *that* badly a job. An Orca user can cope with this grid. It's just not compelling....

2. We are still suffering from problem number 2 because the thing that gets expanded/collapsed is *not* the thing which claims to have focus.

I wanted this in place so that we don't accidentally break what functionality we do have with respect to this treegrid.

As for issues for which we need the guidance of the ARIA experts, I'd like to also ask y'all to try the following:

1. Do NOT launch Orca. :-)
2. Tab into the treegrid.
3. Arrow about within the treegrid.

With focus still in the treegrid:

4. Use Alt+Left to go to the previous page.
5. Use Control+L and/or Alt+D to give focus to the Location bar.
6. Use Alt+F to get into the File menu.
7. Use Control+P to Print.
8. Etc. Etc. Etc.

For me, independent of Orca, I cannot perform steps 4-8. This grid seems to be the great stealer of keystrokes. <snarky aside>Ironic, ain't it? ;-)</snarky aside>
Comment 5 Willie Walker 2009-08-14 15:43:41 UTC
We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place.  Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.