GNOME Bugzilla – Bug 383810
Text selection events not always announced
Last modified: 2007-02-13 21:46:59 UTC
In single line text controls, selection events precede caret movement events rather than follow them. In multiline (well, in gedit; need to confirm for other multiline), selection events follow caret movement rather precede them. The DefaultPerk only works in the later case currently (which also seems to make the most sense). In the former case, the selection announcement is clipped by the following caret movement. Using an inhibitMayStop for the text selection event should help, but isn't the best solution because, in the latter case, we don't want the selection event to continue when the user presses the next key to navigate to another char. Is there another fix? What about "caching" selection events that preceed and announcing them later when we get a caret in the former case?
Inserted inhibitMayStop() for single line text boxes in selection event. Fixed in repository.
Broken when tabbing from one control with selection to another in LSR settings. LSR says "selected 0" instead of text in the control.
The simple text event handler doesn't have a focus handling method. The result is that selector events are fired for single line text boxes, rather than caret movement. Why, I don't know. I'm going to implement focus handler properly and see what happens.
Created attachment 82424 [details] [review] not complete, handles some cases Comments to follow...
There are many situations and implementations of text selection which differ in some key ways to make output from LSR inconsistent. Here are some typical user input events and the resulting AT-SPI events for text entry boxes (gtk, single line), text views (gtk, multiline), and edit bars (XUL, auto complete with drop down): Text entry Focus in (caret not at end) 1. focus 2. selection (whole string) Focus in (caret previously moved from end) 1. focus 2. selection (whole string) 3. movement to end (if not already at end) Shift-Left/Right 1. selection 2. movement Text view Focus in 1. focus Shift-Left/Right 1. movement 2. selection Edit bar Focus in 1. focus 2. movement 3. selection Shift-Left/Right 1. movement 2. selection
Created attachment 82481 [details] [review] done for now Handles most of the cases below by detecting whether or not the caret position as reported by the control matches the pointer POR known to LSR. If it doesn't, a caret movement will be received in the future, and so a selection event should inhibit stopping by the movement. What this patch does not do properly is stop output when doing multiple shift selects in text boxes where selection comes before movement. The next select does not invoke mayStop because, if it did, selections immediately after focus would stop output about the focus. This behavior may be fixable with some thought about how to distinguish the two selection cases.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.