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 536837 - Orca should try to intelligently reposition the cursor in the document frame for tbird and FF during a sayAll
Orca should try to intelligently reposition the cursor in the document frame ...
Status: RESOLVED OBSOLETE
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: FUTURE
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
Depends on:
Blocks: 404403 404409
 
 
Reported: 2008-06-05 16:22 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2015-07-23 21:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Joanmarie Diggs (IRC: joanie) 2008-06-05 16:22:22 UTC
This is a spin-off bug from bug 463223.  The Gecko script for a long time now has repositioned the cursor during the progress callback in a sayAll.  Because the text at the cursor is automatically made visible if you position it off screen, we haven't had the issues in bug 463223.  The trick is deciding where to place the cursor because a caret which bounces at every character is visually distracting and at higher levels of magnification causes the screen to constantly be "jumping around".  As a result, we are looking at the caret offset and the object role and scrolling the text object into view.  Unless the text object is really huge, this seems to buy us the least amount of jumping and scrolling.

What we are not currently handling are pages and email messages in which there are no text objects, but instead all of the text lives in the document frame.  You see this on pages which do not use <p></p>, <div></div>, <Hx></Hx> (where x is the heading level) and in plain text messages in thunderbird.  In these instances we are not positioning the caret, and we should be doing something.

What we might be able to do in those cases is look at the textAtOffset for the line and scroll by the endOffset.  (Come to think of it, maybe that should be done for the proper text objects too).
Comment 1 Joanmarie Diggs (IRC: joanie) 2008-06-05 21:16:27 UTC
(Jotting this down because it just popped in my head, but I'm working on something else atm.)

Thinking about this in terms of magnification, especially at high levels.... What we might could do instead is use the following:

1. Start Offset for the line
2. Some magical number*
3. End Offset for the line

*The magical number would be in between the start offset and the end offset and (somehow) calculated by looking at the magnification level.  (Alternatively we might have to try to get the character at the specified extents, but that strikes me as being harder.  Dunno for sure yet.)  The point is that we need to keep the magnified view/zoomer in mind when moving the caret position and we need to minimize jumpiness.
Comment 2 Trevor Saunders (IRC: tbsaunde) 2011-01-22 15:57:19 UTC
This is really old, what is the status?
Comment 3 Joanmarie Diggs (IRC: joanie) 2011-01-22 18:52:40 UTC
The status is that it might prove to be a pain in the arse, so I've got gotten back to it. :-( Having said that, a number of things which are in Gecko are going to pulled out, more code re-written, bla, bla, bla. And SayAll is on my hit list. So I shall keep this bug in mind for when I tackle that.