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 542840 - We need a Gecko-specific getBrailleContext()
We need a Gecko-specific getBrailleContext()
Status: RESOLVED OBSOLETE
Product: orca
Classification: Applications
Component: braille
2.23.x
Other All
: Normal normal
: FUTURE
Assigned To: Orca Maintainers
Orca Maintainers
post-3.0
Depends on:
Blocks: 404403 404409 527646
 
 
Reported: 2008-07-13 22:51 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2015-07-24 18:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Joanmarie Diggs (IRC: joanie) 2008-07-13 22:51:55 UTC
The script.py for the Gecko toolkit has its own updateBraille() method which does not call braillegenerator.getBrailleContext() like the default script's updateBraille() does.  

Presumably doing a blanket call to getBrailleContext() would result in context being added which we don't necessarily want. In addition, the Gecko toolkit and document content is sufficiently different that once we work out when we should and should not getBrailleContext(), the braillegenerator's getBrailleContext() is not likely to do the right thing in all cases.

I think we need a Gecko-specific getBrailleContext() -- and need to figure out when to invoke it. :-)
Comment 1 Willie Walker 2008-09-03 21:42:47 UTC
The original purpose of getBrailleContext was to include information for labelled containers in the object's hierarchy (e.g., a panel named "Personal Information:" holding several items such as text entry fields for firstname, lastname, address, etc.).  In speech, we try to limit the amount of context spoken by comparing hierarchies from the last object with focus.  In braille, we try to show it all all the way up to the application.

As with speech, we cheated and added row/col header information in as part of the hierarchical context, and we did so in kind of an ungraceful way.  I wondering if it might be possible to try to make a new script method that obtains row/col header information for an object and then call *that* method from the appropriate spots.
Comment 2 Joanmarie Diggs (IRC: joanie) 2010-07-05 14:55:46 UTC
Given everything else on the to-do list, non-critical Gecko bugs are going to have to wait until after 3.0, unless someone volunteers to do them.