GNOME Bugzilla – Bug 515924
Fields in OOo not fully announced when selected/unselected by char
Last modified: 2008-02-14 15:24:21 UTC
Steps to reproduce: 1. Launch OOo Writer. 2. Insert the date (Insert -> Fields -> Date) 3. Move to the beginning of the resulting inserted field and press Shift+Right to select it. Expected results: Orca would speak the entire field. Actual results: Orca speaks only the last digit (e.g. '8 selected') 4. Repeat step 3, but this time instead of using Shift+Right to select the field, use Shift+End. Expected/Actual results: Orca speaks the entire selected field as expected. Note: Similar behaviors can be seen when selecting from the opposite end (i.e. Shift+Left only causes Orca to speak the first character, but Shift+Home causes Orca to speak the entire field). This behavior can also been seen in OOo Calc in the Headers/Footers dialog.
Created attachment 105072 [details] Orca debug output whilst testing this problem. Commentary to follow.
For the Shift-right, we process the following event: vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv OBJECT EVENT: object:text-caret-moved detail=(8,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='' BRAILLE LINE: 'soffice Application Untitled1 - OpenOffice.org Writer Frame Untitled1 - OpenOffice.org Writer RootPane ScrollPane Document view 02/12/08 $l' VISIBLE: '02/12/08 $l', cursor=9 sayCharacter: prev=<0>, char=<8>, startOffset=7, caretOffset=8, endOffset=8, speakBlankLines=True SPEECH OUTPUT: '8' SPEECH OUTPUT: 'selected' ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^ ---- For the Shift-End, we process the following event: vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv OBJECT EVENT: object:text-caret-moved detail=(8,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='' BRAILLE LINE: 'soffice Application Untitled1 - OpenOffice.org Writer Frame Untitled1 - OpenOffice.org Writer RootPane ScrollPane Document view 02/12/08 $l' VISIBLE: '02/12/08 $l', cursor=9 SPEECH OUTPUT: '02/12/08' SPEECH OUTPUT: 'selected' ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^ ---- In both cases, the onCaretMoved() method in the StarOffice.py script calls the onCaretMoved() method in default.py. That in turn calls _presentTextAtNewCaretPosition(). This method has some code to: ... # Guess why the caret moved and say something appropriate. # [[[TODO: WDW - this motion assumes traditional GUI # navigation gestures. In an editor such as vi, line up and # down is done via other actions such as "i" or "j". We may # need to think about this a little harder.]]] # ... In particular: elif (keyString == "Left") or (keyString == "Right"): # If the user has typed Control-Shift-Up or Control-Shift-Dowm, # then we want to speak the text that has just been selected # or unselected, otherwise if the user has typed Control-Left # or Control-Right, we speak the current word otherwise we speak # the character at the text cursor position. # if hasLastPos and isShiftKey and isControlKey: self.sayPhrase(event.source, self.pointOfReference["lastCursorPosition"], text.caretOffset) elif isControlKey: self.sayWord(event.source) else: self.sayCharacter(event.source) So this is causing just a single character to be spoken. I notice that doing a Shift-right from the beginning of a line in gedit or in a normal paragraph in oowriter, just selects one character, so why should it select the whole "line" when we do it after an Insert->Fields->Date? Presumably because it's a single uneditable field/entity. I also noticed that a single right arrow from the beginning of the date field takes you to right to the end. But it's role is just a "paragraph". How can we detect this is something different and add in special-case code to StarOffice.py? Thoughts?
Maybe it's time to "think about this a little harder" (see bug 510231) -- or mark this one as a dupe of the think harder bug and deal with it later, rather than special case it?? After reading your analysis, I tried something else in OOo Writer, namely to select the text of an entire paragraph by moving to the beginning of that paragraph and pressing Control + Shift + Down. Sure enough, we didn't guess quite right and spoke only the last line along with the rather inaccurate 'line selected down from cursor position'. Would it be possible to solve the field case, and the paragraph case, and the vi case, and other cases for other apps we haven't even thought about by always storing our last cursor position and basing our "guess" on our new position relative to the old one?
(In reply to comment #3) > Maybe it's time to "think about this a little harder" (see bug 510231) -- or > mark this one as a dupe of the think harder bug and deal with it later, rather > than special case it?? I agree - we should solve the problem of inferring why the movement occurred and mark this a dup of the 'think about this a little harder' bug. > Would it be possible to solve the field case, and the paragraph case, and the > vi case, and other cases for other apps we haven't even thought about by always > storing our last cursor position and basing our "guess" on our new position > relative to the old one? I think in many cases we can indeed infer what to speak based upon prior/current caret position alone. I think one of the cases we need to consider, however, is whether we speak the character, word, line, etc., if the caret moves from one line to the next. In any case, I think this should be a dup and we should carry on the discussion in bug 510231. Thoughts?
> In any case, I think this should be a dup and we should carry on the discussion > in bug 510231. Thoughts? I agree. And my bad for not recognizing this bug as another instance of bug 510231 in the first place. Sorry Rich!
*** This bug has been marked as a duplicate of 510231 ***