GNOME Bugzilla – Bug 517048
Orca does not always speak the correct information when navigating and/or selecting text across object boundaries in OOo Writer
Last modified: 2008-05-27 19:51:53 UTC
In looking closer at bug #515926, I discovered that it was merely one example of a broader problem in OOo Writer. As the summary indicates, what we say when the user crosses from one paragraph object into another is often "not quite right." Some examples: Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CURRENT: This is a test newline CORRECT: newline -- or newline selected (to be spec'ed) 2. Having done the above, press Shift+Left Arrow to unselect the newline. CURRENT: newline newline CORRECT: newline -- or newline unselected (to be spec'ed) 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) CURRENT: newline test selected CORRECT: test selected 4. Continue to select forward by word to select the period. CURRENT: newline dot selected CORRECT: dot selected 5. Continue to select forward by word to select the newline/ paragraph boundary. CURRENT: dot selected newline so is this unselected CORRECT: newline -- or newline selected (to be spec'ed) 6. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". CURRENT: newline this selected CORRECT: this selected 7. Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CURRENT: So is this selected dot unselected. CORRECT: newline -- or newline selected (to be spec'ed) 8. Continue selecting backwards by word to select "test". CURRENT: newline test selected CORRECT: test selected 9. Start from the beginning of the document. Press Shift+Down to select the current line. CURRENT: This is a test selected so is this unselected. CORRECT: This is a test selected 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CURRENT: dot selected a selected CORRECT: est dot so is this selected 11. Start from the beginning, nav by word with Control+Right until you land on the period. CURRENT: (silence) CORRECT: dot Create a new document: ---------------top of doc-------------- This is a test. So is this. And this. ---------------end of doc-------------- 12. Press Control+Home to move to the top. Select down line by line with Shift+Down. Having selected it all, press Shift+Up twice. "So is this." should just have been unselected. CURRENT: And this. So is this. CORRECT: So is this. unselected
*** Bug 515926 has been marked as a duplicate of this bug. ***
Observations: Aside from the speaking of newline when we shouldn't and not speaking it when we should, the bulk of the issues seem to boil down to the following: _presentTextAtNewCaretPosition() decides what to say based on two things: The key(s) pressed and whether or not we already have the lastCursorPosition in the pointOfReference. The order of events seems to be: - onCaretMoved() - _presentTextAtNewCaretPosition() - say{Character, Word, Line, Phrase}() - speakTextSelectionState() - which stores the lastCursorPosition We seem to dump the pointOfReference in locusOfFocus changed. Therefore, given a document made up of a single text object, the first time we need to present that text (at the end of the process), we establish a lastCursorPosition and update it accordingly. So far so good, and works great when a document consists of a single text object -- be it in Gedit, where pressing Return doesn't cause you to be in a different object, or be it in OOo Writer in a single paragraph. That said.... 1. In OOo Writer, documents are not made up of a single text object, and selections can span multiple text objects. 2. In StarOffice.py, when we get the first focus event for a paragraph as a result of moving into that paragraph from another, we quietly set the locusOfFocus to that paragraph rather than notifying the presentation managers. So we're not trashing the last cursor pos. I tried trashing it in StarOffice.py, and it seems to help the issues slightly, but doesn't resolve them. Nor am I convinced we always want to trash it. But I will leave to that wiser minds. 3. OOo writer tends to spit out caret-moved events for a single keypress like they're going out of style. To make matters more interesting, crossing a paragraph boundary results in some caret- moved events where detail1 == -1. If we do something like call that the starting offset and speak the character (ending offset -1 + 1 == 0), our "character" winds up being the entire text from that object. I believe that the reason why navigation and text selection is not an issue in a single text object, but is given a document made up of several text objects, is that in our pointOfReference's lastCursorPosition merely stores an offset; its lastSelections merely stores a list of selections (i.e. ranges). What I think we want to know in the case of OOo Writer, et al. is not just what is selected (or not) *in this object* but whether or not we have selections in *other objects*. Similarly, given that crossing paragraph boundaries results in some caret-moved events for an offset of -1, I think we might be interested in knowing not merely if *something* has the last caretPosition, but if *this particular object* does. But that's just a hunch (which I admittedly then acted upon in a trial patch with overall positive results). In trying to implement something based on my hunch, I came across another issue in the form of some unexpected failures which I couldn't initially figure out for the life of me. After some more debugging and hair pulling, I concluded that OOo Writer was sometimes giving us different accessibles for what (in theory) is the same object. These instances of the "same" object failed to produce the same hash number as well as failed the isSameObject() test. <grumble, grumble> I have a hack for that as well though which worked. Lastly, out of curiosity, I grabbed the BEFORE-PYATSPI tagged Orca to see if these issues existed way back then. They did. We just didn't notice them, which is rather unfortunate. At least now that we know about them, we can not only fix them but get some good regression tests written (i.e. based on the examples in the opening comment/report) and use those test cases to examine the state of navigation and selection in other apps (e.g. Evo).
Created attachment 105452 [details] [review] revision 1 (needs work) Will had asked Rich and me to look at this and some other related issues and then divide the labor, come up with an attack plan, etc. It was hard to determine which issues were the same and which were different without really looking at all of the issues (not all listed in this bug) and the code. So I volunteered to do some of that. This patch is the result. It needs some work. Rich volunteered to take it over, and I am about to assign it to him before he can take a closer look and change his mind. ;-) ;-) ;-) Thank you Rich!! On the positive side, this bug fixes all of the above issues, but issue number #10: 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CURRENT: dot selected a selected CORRECT: est dot so is this selected To make matters worse, it causes that same issue to be broken in Gedit (whereas currently it is only broken in OOo Writer). :-( I really don't get how to handle that case across the multiple scenarios.... The offending part of the patch (less some indentation so that it will fit here) is: + if isShiftKey and not isControlKey: + if keyString == "Up": + if text.caretOffset == -1: + # We selected the previous line, but we're still + # officially on this line. + # + selList = [] + + # In a document consisting of multiple text objects, + # if we're unselecting text from the bottom up, we'll + # initially get an event for the line we started on + # whose text is not selected (the state of which was + # announced with the previous key press). We want to + # ignore this line. + # + hasLastPos = hasLastPos and len(selList) > 0 But if I remove that, we say extra stuff we shouldn't in OOo Writer. Rich, I'm hoping you have brilliant insight on that one. :-) Getting back to the positive, in functional testing in Gedit, I don't think I broke anything else. ;-) We need to write up a bunch of regression tests to verify that. There are two things we'll need specs/guidance on from Mike. But to be sure those questions don't get lost in all this stuff I'm posting, I will make that a separate comment. Really sorry for the spam.
Mike: Question #1: In comparing what we do in Gedit with what we do in OOo Writer, I noticed an inconsistency, namely in Gedit when moving by character or by word, we only indicate that we've moved to a newline if we encounter a hard return. We do not seem to say newline if the text has wrapped to a new line. This is not what we currently do in OOo Writer. There, we treat all line boundaries (those that result from pressing Return and those that result from text automatically wrapping) as equals and say "newline." I assume we want to be consistent. Therefore, which one is broken, Gedit or OOo Writer? Question #2: In OOo Writer, what should be said if one is selecting/unselecting text and crosses a line boundary? "newline selected"/"newline unselected" or just "newline"? Rich: Related Aside #1: The easiest way to fix the erroneous speaking of the newline characters we were seeing seemed to be to rip out the code that handles that in StarOffice.py. :-) Because of that, with the patch, we only say newline when we cross a paragraph boundary; we don't say it when text has merely wrapped. Related Aside #2: Right now with the patch, we just say "newline". All: I think I'm done commenting on this one. And there was much rejoicing.
Adding Mike's name to the summary for his comments on the two questions for him in comment #4.
Created attachment 105527 [details] Attempt at creating a regression test file for this bug. I think I must be out of touch. When I try to run this test file with: $ cd ~/gnome/orca/trunk/test/harness $ ./runone.sh ../keystrokes/oowriter/bug_517048.py oowriter 0 Each of the tests fails with something like: Test 1 of 12 FAILED: ../keystrokes/oowriter/bug_517048.py:Selecting newline EXPECTED: "XXX: to complete.", ACTUAL: "", [FAILURE WAS UNEXPECTED] Looking at the "bug_517048.debug" file, I see: Traceback (most recent call last):
+ Trace 189632
[stringIO, handler] = loggingStreamHandlers[logger]
Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/orca/httpserver.py", line 141, in do_POST [stringIO, handler] = loggingStreamHandlers[logger] KeyError: 'speech' for each failure. Am I missing something? I'm using the latest Orca.
> Question #1: In comparing what we do in Gedit with what we do in OOo Writer, I > noticed an inconsistency, namely in Gedit when moving by character or by word, > we only indicate that we've moved to a newline if we encounter a hard return. > We do not seem to say newline if the text has wrapped to a new line. This is > not what we currently do in OOo Writer. There, we treat all line boundaries > (those that result from pressing Return and those that result from text > automatically wrapping) as equals and say "newline." I assume we want to be > consistent. Therefore, which one is broken, Gedit or OOo Writer? > In my opinion gedit is the one that is broken. > Question #2: In OOo Writer, what should be said if one is selecting/unselecting > text and crosses a line boundary? "newline selected"/"newline unselected" or > just "newline"? > I'd prefer to hear just "new line"
> Am I missing something? I'm using the latest Orca. The general pattern is this: 1. Get to the point where you want to test something. This is typically done by playing keystrokes and waiting for something to get focus. *2. Tell Orca to start recording: sequence.append(utils.StartRecordingAction()) 3. Do the keystrokes for the specific test, causing Orca to present something. 4. Assert that the presentation Orca made is what was expected: sequence.append(utils.AssertPresentationAction( "Left resize check box unchecked plus panel context", ["BRAILLE LINE: 'gtk-demo Application Panes Frame Horizontal Panel < > Resize CheckBox'", " VISIBLE: '< > Resize CheckBox', cursor=1", "SPEECH OUTPUT: 'Horizontal panel'", "SPEECH OUTPUT: 'Resize check box not checked'"])) 5) Repeat 1-4 as many times as you'd like for different tests in the file. 6) Then, at the very end of the file, output summary information and tell the tests to run: sequence.append(utils.AssertionSummaryAction()) sequence.start() [*] - I think this is the step you're missing.
Created attachment 105539 [details] [review] Revision #2 (needs work). I'm getting two differences from what Joanie says are correct: Test 9. Press Control-Home to start from the beginning of the document. Press Shift-Down Arrow to select the current line. According to Joanie, this should say: SPEECH OUTPUT: 'This is a test.' SPEECH OUTPUT: 'selected' Currently it's saying: SPEECH OUTPUT: 'This is a test.' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'So is this.' SPEECH OUTPUT: 'unselected' Test 10: Start from the end of the document (by pressing Control+End). Press Shift-Up Arrow to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). According to Joanie, this should say: SPEECH OUTPUT: 'est. So is this.' SPEECH OUTPUT: 'selected' Currently it's saying: SPEECH OUTPUT: 'est.' SPEECH OUTPUT: 'selected' The result of test #10 was expected as Joanie was seeing this, but I'm getting an unexpected failure for test #9. I'll investigate further tomorrow.
Oops. Forgot to mention: > *2. Tell Orca to start recording: > sequence.append(utils.StartRecordingAction()) > ... > [*] - I think this is the step you're missing. Yup, that was it. Thanks.
Created attachment 105557 [details] Regression test file with just tests #9 and #10 in it. This is really weird. If I use the bug_517048.py regression test file, both test #9 and #10 fail for me. If I just isolate those two tests into a single file (the attached junk.py), then test #9 *the first of the two) works correctly. Hmmph. I'll look at it closer tomorrow. There must be something funky happening at the end of test #8 in bug_517048.py that's generous spurious results in the next test.
Created attachment 105595 [details] [review] Revision #3 (needs work). Divided the regression tests into two files. Now only test #10 is failed (like Joanie originally found).
Created attachment 105617 [details] Test file to play with This test file peppers the following events throughout the test and eliminates a number of PauseAction methods. Listening for specific events is definitely preferred over PauseAction's when possible because it can speed the tests along while also making sure the app is in the state needed to conduct the test. sequence.append(WaitAction("object:text-caret-moved", None, None, pyatspi.ROLE_PARAGRAPH, 5000)) Of course, it didn't solve the problems for me. :-( I'm getting a bunch of whitespace differences where the VISIBLE text is beginning with a blank (odd). For example: EXPECTED: " VISIBLE: 'So is this. $l', cursor=1", ACTUAL: " VISIBLE: ' So is this. $l', cursor=1", In looking at the EXPECTED output in the tests, I'm also seeing what *might* be incorrect output with respect to including the overall context on the braille line. Here's an example: "BRAILLE LINE: 'This is a test. $l'", " VISIBLE: 'This is a test. $l', cursor=1", "BRAILLE LINE: 'soffice Application Untitled1 - OpenOffice.org Writer Frame Untitled1 - OpenOffice.org Writer RootPane ScrollPane Document view So is this. $l'", If I recall from fixing a gnome-terminal bug recently, the BRAILLE LINE should include the context information only if we're on the first line in a file. Otherwise, it should be just the text and panning left on the braille display should take us back through the text until we reach the first line. Is that correct, Mike?
Created attachment 105622 [details] [review] Revision #4 (needs work) Adjusted the two regression test files to use oodles of: sequence.append(WaitAction("object:text-caret-moved", None, None, pyatspi.ROLE_PARAGRAPH, 5000)) instead of: sequence.append(PauseAction(3000))
Created attachment 105646 [details] Test #10 - scenerio #1 Commentary to follow.
Created attachment 105647 [details] Test #10 - scenerio #2 Commentary to follow.
I'm trying to work out how to fix test case #10. We have an oowriter document with the following two lines of text in it: This is a test. So is this. Test #10 says: Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CURRENT: dot selected a selected CORRECT: est dot so is this selected I've just tested this and got two different sets of results depending upon what I did. -------- Case #1: * Oowriter is already started with the two lines of text present. Text caret is to the right of the "h" on the first line. * Start Orca. * Give focus to the oowriter window. * Type Control-End to get to the end of the document. * Type Shift-Up to move up a line (selecting text). We speak: SPEECH OUTPUT: 'This is a test.' (at line 465 in test-case1.txt) because of an "object:text-caret-moved" event: OBJECT EVENT: object:text-caret-moved detail=(11,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='flows to' -------- Case #2: * Oowriter is already started with the two lines of text present. Text caret is to the right of the "h" on the first line. * Start Orca. * Give focus to the oowriter window. * Type Control-Home to get to the start of the document. * Type Shift-Down to move down a line (selecting text). * Type Control-End to get to the end of the document. * Type Shift-Up to move up a line (selecting text). We speak: SPEECH OUTPUT: 'est.' SPEECH OUTPUT: 'selected' (at line 937 in test-case2.txt) because of the same apparent "object:text-caret-moved" event: OBJECT EVENT: object:text-caret-moved detail=(11,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='flows to'
I just spoke with Will about this bug. From looking at bug #517127 (Orca doesn't always speak expected message when selecting all), we know that there currently isn't a listener in Orca for "object:text-selection-changed" events. In order to fix that bug, we are going to have to introduce that new listener. Fixing that bug is going to affect all other applications that generate these events. One of those applications is oowriter (and presumably the rest of the OpenOffice suite). Currently we try to give the text selection state after events like "object:text-caret-moved". When we introduce the new listener we are probably going to have to speak/braille text selection state in the new listener and not do it as the result of events like "object:text-caret-moved". In short, there will need to be a significant refactor in this area. Rather than spend a lot of time now trying to track down and fix the remaining problem(s) for case #10, we propose the following: 1/ Get Mike to test the latest patch: http://bugzilla.gnome.org/attachment.cgi?id=105622 that's attached to this bug, which we believe is a vast improvement over what's currently there (thanks Joanie!) 2/ If/when Mike give the word, check this patch in for Orca v2.21.92, but keep the bug open for further investigation after GNOME 2.20. 3/ After GNOME 2.22, add in the new listener for "object:text-selection-changed" events and do the refactor and see what changes needed to be done to this new selection handling code in _presentTextAtNewCaretPosition(). 4/ Make sure the refactor correctly fixes the 12 test cases for this bug. So Mike, could you please give the patch a good testing and let us know what you find. Thanks.
(In reply to comment #18) > I just spoke with Will about this bug. Rich, Joanie, Mike and I also spoke more about this. Given where we are in the release cycle, no end user has reported this problem so far, this touches more than just the OOo code, and there's this text selection event that we're not using, the safest thing to do right now is to evaluate/fix this after we branch for GNOME 2.23 (some time today). If the ultimate fix is then deemed to be relatively minor and painless, we can backport it to a GNOME 2.22.{0,1,2,3} release. PS - Yes, I realize the "no user has reported this problem" argument is not strong, but let me explain. ;-) We should always attempt to find/fix problems before our users find them. We're just late in the GNOME 2.22 release cycle right now, however, and I think the safest thing for our users is to keep the core stable if we can.
First coarse pass at GNOME 2.24 planning.
Mike, to save you have to be intimately familar with the whole bug, you should all the information you currently need in comment #18. Thanks.
The patch to bug #517127 to add in support for an "object:text-selection-changed" handler has had an effect on this bug. I also applied patch #10 from bug #520494, just in case that's had any effect on the tests. It doesn't appear to. Here are the current results (without Joanie's patch to this bug being applied). I'll now work out what's still relevant from that patch and what has to be adjusted. ------------------------------------------------------------------------ Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CORRECT: newline -- or newline selected (to be spec'ed) OLD CURRENT: This is a test newline CURRENT: selected ------------------------------------------------------------------------ 2. Having done the above, press Shift+Left Arrow to unselect the newline. CORRECT: newline -- or newline unselected (to be spec'ed) OLD CURRENT: newline newline CURRENT: unselected ------------------------------------------------------------------------ 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) CORRECT: test selected OLD CURRENT: newline test selected CURRENT: newline test selected ------------------------------------------------------------------------ 4. Continue to select forward by word to select the period. CORRECT: dot selected OLD CURRENT: newline dot selected CURRENT: newline unselected ------------------------------------------------------------------------ 5. Continue to select forward by word to select the newline/ paragraph boundary. CORRECT: newline -- or newline selected (to be spec'ed) OLD CURRENT: dot selected newline so is this unselected CURRENT: newline So is this unselected selected ------------------------------------------------------------------------ 6. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". CORRECT: this selected OLD CURRENT: newline this selected CURRENT: newline this selected ------------------------------------------------------------------------ 7. Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CORRECT: newline -- or newline selected (to be spec'ed) OLD CURRENT: So is this selected dot unselected. CURRENT: So is this unselected ------------------------------------------------------------------------ 8. Continue selecting backwards by word to select "test". CORRECT: test selected OLD CURRENT: newline test selected CURRENT: newline test selected ------------------------------------------------------------------------ 9. Start from the beginning of the document. Press Shift+Down to select the current line. CORRECT: This is a test selected OLD CURRENT: This is a test. selected So is this. unselected. CURRENT: This is a test. So is this. selected. ------------------------------------------------------------------------ 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CORRECT: est dot so is this selected OLD CURRENT: dot selected a selected CURRENT: a selected selected ------------------------------------------------------------------------ 11. Start from the beginning, nav by word with Control+Right until you land on the period. CORRECT: dot OLD CURRENT: (silence) CURRENT: (silence) ------------------------------------------------------------------------ Create a new document: ---------------top of doc-------------- This is a test. So is this. And this. ---------------end of doc-------------- ------------------------------------------------------------------------ 12. Press Control+Home to move to the top. Select down line by line with Shift+Down. Having selected it all, press Shift+Up twice. "So is this." should just have been unselected. CORRECT: So is this. unselected OLD CURRENT: And this. So is this. CURRENT: And this. So is this. ------------------------------------------------------------------------
Created attachment 110998 [details] [review] Revision #5 Joanie has been working her magic again. Thanks! This patch dramatically improves the text selection/unselection utterances for the majority of situations and works nicely with the new handler and code for object:text-selection-changed events. There are still a few edge cases (especially around newlines). There is a separate bug for that. I'll post Joanie's 12 test case results (with this patch) in a few moments.
Here's the results from Joanie, of running the twelve test cases against a version of Orca incorporating the latest patch. ------------------------------------------------------------------------ Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: <dead silence> We have another bug all about being silent when we arrow to the end of a line. It is suggested that this problem be fixed as part of that bug. ------------------------------------------------------------------------ 2. Having done the above, press Shift+Left Arrow to unselect the newline. CORRECT: newline -- or newline unselected (to be spec'ed) CURRENT: newline unselected ------------------------------------------------------------------------ 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) CORRECT: test selected CURRENT: test selected ------------------------------------------------------------------------ 4. Continue to select forward by word to select the period. CORRECT: dot selected CURRENT: dot selected ------------------------------------------------------------------------ 5. Continue to select forward by word to select the newline/ paragraph boundary. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: So We are on the word "So" and we aren't saying anything about its selection state, which we think is correct. We didn't say newline (newline bug). ------------------------------------------------------------------------ 6. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". CORRECT: this selected CURRENT: this selected ------------------------------------------------------------------------ 7. Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: newline ------------------------------------------------------------------------ 8. Continue selecting backwards by word to select "test". CORRECT: test selected CURRENT: test selected ------------------------------------------------------------------------ 9. Start from the beginning of the document. Press Shift+Down to select the current line. CORRECT: This is a test. selected CURRENT: This is a test. selected ------------------------------------------------------------------------ 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CORRECT: est dot so is this selected CURRENT: est. So is this. selected. ------------------------------------------------------------------------ 11. Start from the beginning, nav by word with Control+Right until you land on the period. CORRECT: dot CURRENT: dot ------------------------------------------------------------------------ Create a new document: ---------------top of doc-------------- This is a test. So is this. And this. ---------------end of doc-------------- ------------------------------------------------------------------------ 12. Press Control+Home to move to the top. Select down line by line with Shift+Down. Having selected it all, press Shift+Up twice. "So is this." should just have been unselected. CORRECT: So is this. unselected JD CURRENT: So is this. Looks like a special case we are not currently handling. =======================================================================
I've just tested this patch and was not able to cause the false unselected messages in naudilus. I'm not sure what was up with that or if it was related to this patch or not but the problem seems gone now.
Created attachment 111006 [details] Gtk+ regression test results after applying rev. #5 of the patch. Here's the overall summary: SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/debug_commands.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/learn_mode.py SUMMARY: 7 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_accel_label.py SUMMARY: 3 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_alert.py SUMMARY: 14 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_menu_item.py SUMMARY: 9 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box2.py SUMMARY: 15 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 15 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_dialog.py SUMMARY: 7 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_icon.py SUMMARY: 6 SUCCEEDED and 3 FAILED (3 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py SUMMARY: 8 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 8 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_menu.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_page_tab.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_push_button.py SUMMARY: 3 SUCCEEDED and 2 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_menu_item.py SUMMARY: 5 SUCCEEDED and 2 FAILED (1 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_split_pane.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_status_bar.py SUMMARY: 6 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_table.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tear_off_menu_item.py SUMMARY: 12 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 12 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py SUMMARY: 87 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 87 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py SUMMARY: 10 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline.py SUMMARY: 5 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toggle_button.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toolbar.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tooltip.py SUMMARY: 14 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tree_table.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_window.py Here are the differences in more detail: ------------------------------ SUMMARY: 9 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application GtkListStore demo Frame ScrollPane Table' VISIBLE: 'Table', cursor=1 BRAILLE LINE: 'gtk-demo Application GtkListStore demo Frame ScrollPane Table Description ColumnHeader < > Fixed? 60482 Normal scrollable notebooks and hidden tabs' VISIBLE: 'scrollable notebooks and hidden ', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'table' SPEECH OUTPUT: '' SPEECH OUTPUT: 'Description column header' SPEECH OUTPUT: 'Fixed? check box not checked 60482 Normal scrollable notebooks and hidden tabs' + SPEECH OUTPUT: ' not selected' [FAILURE WAS UNEXPECTED] This is now correct behaviour on Ubuntu Hardy with GNOME 2.22. When you first enter a table from the column headers, it's not selected. Unfortunately this isn't the situation on Solaris. :-( ------------------------------ SUMMARY: 6 SUCCEEDED and 3 FAILED (3 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py Test #4 DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' VISIBLE: 'This message box has been popped', cursor=1 BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' VISIBLE: 'This message box has been popped', cursor=2 SPEECH OUTPUT: 'T' - SPEECH OUTPUT: 'unselected' SPEECH OUTPUT: 'h' [FAILURE WAS UNEXPECTED] This was changed as adjustments to the regression tests for bug #517127. See comment #25: http://bugzilla.gnome.org/show_bug.cgi?id=517127#c25 ---- Test #5 failures is a known bug: DIFFERENCES FOUND: - BUG? - no selection is announced? + BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' + VISIBLE: 'This message box has been popped', cursor=2 [FAILURE WAS UNEXPECTED] ---- Test #8 is the same as test #4 (see above). DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' VISIBLE: 'This message box has been popped', cursor=2 BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' VISIBLE: 'This message box has been popped', cursor=1 SPEECH OUTPUT: 'h' - SPEECH OUTPUT: 'unselected' SPEECH OUTPUT: 'T' SPEECH OUTPUT: 'selected' [FAILURE WAS UNEXPECTED] Do we want to readjust tests #4 and #8 back the way they were? ------------------------------ SUMMARY: 3 SUCCEEDED and 2 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py Both failures are known issues. ------------------------------ SUMMARY: 5 SUCCEEDED and 2 FAILED (1 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py First failure is a known bug. Second failure is a known issue but it's also no longer saying "unselected", a change to the regression test because of bug #517127: DIFFERENCES FOUND: - KNOWN ISSUE - Value should be 239 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=9 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=6 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=6 SPEECH OUTPUT: '240' - SPEECH OUTPUT: 'unselected' SPEECH OUTPUT: '240' [FAILURE WAS EXPECTED - LOOK FOR KNOWN ISSUE IN EXPECTED RESULTS] Do we want to set the regression test back the way it was? ------------------------------ SUMMARY: 6 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_table.py This one appears to majorly different and I'm not sure why: DIFFERENCES FOUND: BRAILLE LINE: 'Window Editable Cells $l' VISIBLE: 'Window Editable Cells $l', cursor=22 BRAILLE LINE: 'Window $l' VISIBLE: 'Window $l', cursor=8 BRAILLE LINE: 'Window $l' VISIBLE: 'Window $l', cursor=8 BRAILLE LINE: 'gtk-demo Application GTK+ Code Demos Frame TabList Widget (double click for demo) Page ScrollPane TreeTable Widget (double click for demo) ColumnHeader Editable Cells TREE LEVEL 2' VISIBLE: 'Editable Cells TREE LEVEL 2', cursor=1 BRAILLE LINE: 'gtk-demo Application Shopping list Frame' VISIBLE: 'Shopping list Frame', cursor=1 + BRAILLE LINE: 'gtk-demo Application Shopping list Frame ScrollPane Table' + VISIBLE: 'Table', cursor=1 - BRAILLE LINE: 'gtk-demo Application Shopping list Frame ScrollPane Table Number ColumnHeader 3 bottles of coke[ ]*' ? ---- + BRAILLE LINE: 'gtk-demo Application Shopping list Frame ScrollPane Table Number ColumnHeader 3 bottles of coke' - VISIBLE: '3 bottles of coke[ ]*', cursor=1 ? ---- + VISIBLE: '3 bottles of coke', cursor=1 SPEECH OUTPUT: 'Widget (double click for demo) column header' SPEECH OUTPUT: 'Editable Cells' SPEECH OUTPUT: 'tree level 2' SPEECH OUTPUT: 'Shopping list frame' SPEECH OUTPUT: '' + SPEECH OUTPUT: 'table' + SPEECH OUTPUT: '' SPEECH OUTPUT: 'Number column header' - SPEECH OUTPUT: '3 bottles of coke[ ]*' ? ---- + SPEECH OUTPUT: '3 bottles of coke' [FAILURE WAS UNEXPECTED] ------------------------------
Created attachment 111007 [details] Oowriter regression test results after applying rev #5 of the patch. Here's the overall summaries: SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_342602.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_350219.py SUMMARY: 0 SUCCEEDED and 3 FAILED (3 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_353268.py SUMMARY: 1 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_355733.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_361624.py SUMMARY: 1 SUCCEEDED and 3 FAILED (3 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_361747.py SUMMARY: 0 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_362979.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_364765.py SUMMARY: 0 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_382408.py SUMMARY: 0 SUCCEEDED and 5 FAILED (5 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_382415.py SUMMARY: 0 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_382418.py SUMMARY: 0 SUCCEEDED and 8 FAILED (8 UNEXPECTED) of 8 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_382880.py SUMMARY: 0 SUCCEEDED and 8 FAILED (8 UNEXPECTED) of 8 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_382888.py SUMMARY: 2 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_384893.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_385828.py SUMMARY: 0 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_413909.py SUMMARY: 1 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_430402.py SUMMARY: 0 SUCCEEDED and 5 FAILED (5 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_435201.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_435226.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_450210.py SUMMARY: 1 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oowriter/bug_469367.py Lots of unexpected differences here, and to be honest, from looking at the results, it's unclear how this patch could have caused some of them. Is it possible that another recent Orca checkin has had an adverse effect on the oowriter regression test results?
Created attachment 111008 [details] Oocalc regression test results after applying rev. #5 of the patch. Here's a summary of the summaries: SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_356334.py SUMMARY: 10 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_361167.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_363801.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_363802.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_363804.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_364086.py SUMMARY: 2 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_364407.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_433398.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_435307.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_435852.py Here's more information on the differences: ------------------------------------- SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_356334.py These are two known bugs. ------------------------------------- SUMMARY: 2 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/oocalc/bug_364407.py Test #1 is now no longer speaking a blank line. This might be a good thing. DIFFERENCES FOUND: BRAILLE LINE: 'soffice Application Untitled2 - OpenOffice.org Calc Frame' VISIBLE: 'Untitled2 - OpenOffice.org Calc ', cursor=1 BRAILLE LINE: 'soffice Application Untitled2 - OpenOffice.org Calc Frame Untitled2 - OpenOffice.org Calc RootPane Panel' VISIBLE: 'Panel', cursor=1 BRAILLE LINE: 'soffice Application Untitled2 - OpenOffice.org Calc Frame Untitled2 - OpenOffice.org Calc RootPane ScrollPane Document view3 Sheet Sheet1 Table' VISIBLE: 'Sheet Sheet1 Table', cursor=1 BRAILLE LINE: 'soffice Application Untitled2 - OpenOffice.org Calc Frame Untitled2 - OpenOffice.org Calc RootPane ScrollPane Document view3 Sheet Sheet1 Table Cell A1 ' VISIBLE: 'Cell A1 ', cursor=1 - SPEECH OUTPUT: '' SPEECH OUTPUT: 'Untitled2 - OpenOffice.org Calc frame' SPEECH OUTPUT: '' SPEECH OUTPUT: 'panel' SPEECH OUTPUT: 'Sheet Sheet1 table grayed' SPEECH OUTPUT: ' A1' [FAILURE WAS UNEXPECTED] -------------------------------------
Created attachment 111163 [details] [review] Revision #6. For some reason, revision #5 of the patch didn't have the change needed to .../src/orca/scripts/app/gedit/Makefile.am and was missing part of the change to ../src/orca/scripts/app/gedit/script.py. Attaching a new version that fixes that.
I've been looking at the problem of issue #12 not saying "unselected" after the second Shift-Up. See the end of comment #24 above. After the first Shift-Up we get the following event: OBJECT EVENT: object:text-selection-changed detail=(0,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='flows from flows to' This nicely speaks: SPEECH OUTPUT: 'unselected' but the last thing it does in speakTextSelectionState() is call _saveLastTextSelections(). Because there are no text selections in the 'text' variable that's being passed in, self.pointOfReference["lastSelections"] is being set to an empty list. Now we press the second Shift-Up and we get the following event: OBJECT EVENT: object:text-selection-changed detail=(0,0) app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations='flows from flows to' In speakTextSelectionState(), it gets to the else: section below: if self.isTextSelected(obj, startOffset, endOffset): # Translators: when the user selects (highlights) text in # a document, Orca lets them know this. # # ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | # speech.speak(Q_("text|selected"), None, False) else: if self.pointOfReference.has_key("lastSelections"): for i in xrange(len(self.pointOfReference["lastSelections"])): startSelOffset = \ self.pointOfReference["lastSelections"][0][0] endSelOffset = \ self.pointOfReference["lastSelections"][0][1] if (startOffset >= startSelOffset) \ and (endOffset <= endSelOffset): # Translators: when the user unselects # (unhighlights) text in a document, Orca lets # them know this. # # ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | # speech.speak(Q_("text|unselected"), None, False) break but because self.pointOfReference["lastSelections"] is an empty list, it doesn't speak "unselected"; (doesn't get into the for loop). That's what's causing the problem. I'm not sure how to fix it though. Unless we alway speak "unselected" if there are no selections (we are in the middle of processing an "object:text-selection-changed" event on a FOCUSED object after all.
Using rev #6 of the patch, I tried the 12 tests. Results given below as "RB LATEST:". I then commented out that chunk of code in the else: statement: ###if self.pointOfReference.has_key("lastSelections"): ### for i in xrange(len(self.pointOfReference["lastSelections"])): ### startSelOffset = \ ### self.pointOfReference["lastSelections"][0][0] ### endSelOffset = \ ### self.pointOfReference["lastSelections"][0][1] ### if (startOffset >= startSelOffset) \ ### and (endOffset <= endSelOffset): ### # Translators: when the user unselects ### # (unhighlights) text in a document, Orca lets ### # them know this. ### # ### # ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | ### # ### speech.speak(Q_("text|unselected"), None, False) ### break and replaced it with: # Translators: when the user unselects # (unhighlights) text in a document, Orca lets # them know this. # # ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | # speech.speak(Q_("text|unselected"), None, False) I then ran the 12 tests again (see: "RB CHUNK REMOVED"). In short, it fixed test #12, but broke another one. I'm also seeing anomalies when we select/unselect "." characters. I'm using punctuation level "Some" with Cestral Swift TTS (gnome-speech). -------------------------------------------------------------------- Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: <dead silence> RB LATEST: selected RB CHUNK REMOVED: selected We have another bug all about being silent when we arrow to the end of a line. It is suggested that this problem be fixed as part of that bug. ------------------------------------------------------------------------ 2. Having done the above, press Shift+Left Arrow to unselect the newline. CORRECT: newline -- or newline unselected (to be spec'ed) CURRENT: newline unselected RB LATEST: unselected RB CHUNK REMOVED: unselected ------------------------------------------------------------------------ 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) CORRECT: test selected CURRENT: test selected RB LATEST: test selected RB CHUNK REMOVED: test selected ------------------------------------------------------------------------ 4. Continue to select forward by word to select the period. CORRECT: dot selected CURRENT: dot selected RB LATEST: unselected RB CHUNK REMOVED: unselected ------------------------------------------------------------------------ 5. Continue to select forward by word to select the newline/ paragraph boundary. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: So RB LATEST: So RB CHUNK REMOVED: So unselected We are on the word "So" and we aren't saying anything about its selection state, which we think is correct. We didn't say newline (newline bug). ------------------------------------------------------------------------ 6. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". CORRECT: this selected CURRENT: this selected RB LATEST: this selected RB CHUNK REMOVED: this selected ------------------------------------------------------------------------ 7. Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: newline RB LATEST: newline RB CHUNK REMOVED: newline ------------------------------------------------------------------------ 8. Continue selecting backwards by word to select "test". CORRECT: test selected CURRENT: test selected RB LATEST: test selected RB CHUNK REMOVED: test selected ------------------------------------------------------------------------ 9. Start from the beginning of the document. Press Shift+Down to select the current line. CORRECT: This is a test. selected CURRENT: This is a test. selected RB LATEST: This is a test selected RB CHUNK REMOVED: This is a test selected ------------------------------------------------------------------------ 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CORRECT: est dot so is this selected CURRENT: est. So is this. selected. RB LATEST: est So is this selected RB CHUNK REMOVED: est So is this unselected unselected ------------------------------------------------------------------------ 11. Start from the beginning, nav by word with Control+Right until you land on the period. CORRECT: dot CURRENT: dot RB LATEST: dot RB CHUNK REMOVED: dot ------------------------------------------------------------------------ Create a new document: ---------------top of doc-------------- This is a test. So is this. And this. ---------------end of doc-------------- ------------------------------------------------------------------------ 12. Press Control+Home to move to the top. Select down line by line with Shift+Down. Having selected it all, press Shift+Up twice. "So is this." should just have been unselected. CORRECT: So is this. unselected CURRENT: So is this. RB LATEST: So is this RB CHUNK REMOVED: So is this unselected. Looks like a special case we are not currently handling. =======================================================================
Created attachment 111177 [details] [review] revision #6a What about this Rich?
Thanks Joanie. Using rev #6a of the patch, I tried the 12 tests. Results given below as "RB LATEST:". By my reckoning, tests #4 and #5 aren't working correctly for me, (where they were working before) and test #12 is noe working (where it wasn't before). -------------------------------------------------------------------- Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CORRECT: newline -- or newline selected (to be spec'ed) RB LATEST: selected ------------------------------------------------------------------------ 2. Having done the above, press Shift+Left Arrow to unselect the newline. CORRECT: newline -- or newline unselected (to be spec'ed) RB LATEST: unselected ------------------------------------------------------------------------ 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) CORRECT: test selected RB LATEST: test selected ------------------------------------------------------------------------ 4. Continue to select forward by word to select the period. CORRECT: dot selected RB LATEST: dot ------------------------------------------------------------------------ 5. Continue to select forward by word to select the newline/ paragraph boundary. CORRECT: newline -- or newline selected (to be spec'ed) RB LATEST: <silence> ------------------------------------------------------------------------ 6. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". CORRECT: this selected RB LATEST: this selected ------------------------------------------------------------------------ 7. Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CORRECT: newline -- or newline selected (to be spec'ed) RB LATEST: newline ------------------------------------------------------------------------ 8. Continue selecting backwards by word to select "test". CORRECT: test selected RB LATEST: test selected ------------------------------------------------------------------------ 9. Start from the beginning of the document. Press Shift+Down to select the current line. CORRECT: This is a test. selected RB LATEST: This is a test. selected ------------------------------------------------------------------------ 10. Start from the end of the document (by pressing Control+End). Use Shift+Up to select a line's worth (thus "So is this." on the last line is selected, along with "est." at the end of the previous line). CORRECT: est dot so is this selected RB LATEST: est. So is this. selected ------------------------------------------------------------------------ 11. Start from the beginning, nav by word with Control+Right until you land on the period. CORRECT: dot RB LATEST: dot ------------------------------------------------------------------------ Create a new document: ---------------top of doc-------------- This is a test. So is this. And this. ---------------end of doc-------------- ------------------------------------------------------------------------ 12. Press Control+Home to move to the top. Select down line by line with Shift+Down. Having selected it all, press Shift+Up twice. "So is this." should just have been unselected. CORRECT: So is this. unselected RB LATEST: So is this. unselected. ======================================================================= I'm now going to try running the Gtk+ regression tests.
Rich on #4, I get "dot selected" (Dunno why you aren't). On #5, that's an intentional change. If we are selecting by word and cross an object boundary, and have not selected the next word, I personally think what we should do is announce the newline. We aren't (that's the newline bug), but I don't think we should be saying "so" in that instance.
Created attachment 111185 [details] Results od running the Gtk+ regression tests after applying patch 6a Here are the failing ones: SUMMARY: 9 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py SUMMARY: 8 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py SUMMARY: 3 SUCCEEDED and 2 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py SUMMARY: 5 SUCCEEDED and 2 FAILED (1 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py SUMMARY: 8 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 12 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py SUMMARY: 9 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline.py Here are the differences in more detail. There appear to be improvements and regressions. Tests #2-4 of role_text_multiline_navigation2.py appear to be the only serious regressions. ----------------- Test 3 of 10 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py:Enter table for first time DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application GtkListStore demo Frame ScrollPane Table' VISIBLE: 'Table', cursor=1 BRAILLE LINE: 'gtk-demo Application GtkListStore demo Frame ScrollPane Table Description ColumnHeader < > Fixed? 60482 Normal scrollable notebooks and hidden tabs' VISIBLE: 'scrollable notebooks and hidden ', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'table' SPEECH OUTPUT: '' SPEECH OUTPUT: 'Description column header' SPEECH OUTPUT: 'Fixed? check box not checked 60482 Normal scrollable notebooks and hidden tabs' + SPEECH OUTPUT: ' not selected' [FAILURE WAS UNEXPECTED] This was changed as adjustments to the regression tests for bug #517127. http://bugzilla.gnome.org/show_bug.cgi?id=517127#c25 ----------------- Test 5 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret select 'his' of 'This' DIFFERENCES FOUND: - BUG? - no selection is announced? + BRAILLE LINE: 'gtk-demo Application Information Alert This message box has been popped up the following $l' + VISIBLE: 'This message box has been popped', cursor=2 [FAILURE WAS UNEXPECTED] Known bug. ----------------- Test 3 of 5 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py:Range radio button DIFFERENCES FOUND: - KNOWN ISSUE - the radio button should be presented as selected. BRAILLE LINE: 'gtk-demo Application Print Dialog TabList General Page Print Pages Filler & y Range RadioButton' VISIBLE: '& y Range RadioButton', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'Range not selected radio button' [FAILURE WAS EXPECTED - LOOK FOR KNOWN ISSUE IN EXPECTED RESULTS] Known issue. Test 5 of 5 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py:All radio button DIFFERENCES FOUND: - KNOWN ISSUE - the radio button should be presented as selected. BRAILLE LINE: 'gtk-demo Application Print Dialog TabList General Page Print Pages Filler & y All RadioButton' VISIBLE: '& y All RadioButton', cursor=1 SPEECH OUTPUT: '' SPEECH OUTPUT: 'All not selected radio button' [FAILURE WAS EXPECTED - LOOK FOR KNOWN ISSUE IN EXPECTED RESULTS] Known issue. ----------------- Test 1 of 7 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py:Hue spin button DIFFERENCES FOUND: - BUG? - Text is selected, but selection not presented. BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=6 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=9 SPEECH OUTPUT: '' SPEECH OUTPUT: 'Hue: 240 spin button' [FAILURE WAS UNEXPECTED] Known bug. Test 4 of 7 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py:Hue spin button decrement value DIFFERENCES FOUND: - KNOWN ISSUE - Value should be 239 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=9 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=6 BRAILLE LINE: 'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l' VISIBLE: 'Hue: 240 $l', cursor=6 SPEECH OUTPUT: '240' - SPEECH OUTPUT: 'unselected' SPEECH OUTPUT: '240' [FAILURE WAS EXPECTED - LOOK FOR KNOWN ISSUE IN EXPECTED RESULTS] Known issue. ----------------- Test 2 of 12 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py:Shift+Ctrl+Page_Down to select text to end of line DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=21 SPEECH OUTPUT: 'This is only a test.' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] This would appear to be a problem. Test 3 of 12 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py:Shift+Up to select text DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application Application Window Frame ScrollPane This is a test. $l' VISIBLE: 'This is a test. $l', cursor=17 SPEECH OUTPUT: ' This is only a test.' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] This would appear to be a problem. Test 4 of 12 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py:Shift+Down to deselect text DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=21 SPEECH OUTPUT: ' This is only a test.' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] This would appear to be a problem. Test 5 of 12 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation2.py:Ctrl+Page_Up to beginning of line DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=1 SPEECH OUTPUT: 'T' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] This would appear to be a good improvement. ----------------- Test 7 of 10 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline.py:Select to end of line DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application Application Window Frame ScrollPane This is a test. $l' VISIBLE: 'This is a test. $l', cursor=1 BRAILLE LINE: ' $l' VISIBLE: ' $l', cursor=1 BRAILLE LINE: 'I'm just typing away like a mad little monkey with nothing better to do in my life than eat fruit and type. $l' VISIBLE: 'I'm just typing away like a mad ', cursor=1 BRAILLE LINE: 'I'm just typing away like a mad little monkey with nothing better to do in my life than eat fruit and type. $l' VISIBLE: 'y life than eat fruit and type. ', cursor=32 SPEECH OUTPUT: 'T' + SPEECH OUTPUT: 'unselected' SPEECH OUTPUT: 'blank' SPEECH OUTPUT: 'I'm just typing away like a mad little monkey with nothing better to do in my life than eat fruit and type.' SPEECH OUTPUT: 'I'm just typing away like a mad little monkey with nothing better to do in my life than eat fruit and type.' SPEECH OUTPUT: 'selected' [FAILURE WAS UNEXPECTED] This would appear to be a good improvement. -----------------
For the three tests that appear to have regressed in role_text_multiline_navigation2.py with the latest patch (tests #2-4), the following simple test will show how to replicate them: * Start up orca. * Start up the gtk-demo "Application main window" test. * Add the following two lines to the text area: This is a test. This is only a test. Each line should be followed by a Return character. * Press Control-End to make sure you are at the end of the text. * Position the cursor on the second line, just after the first space. with: Up, Right, Right, Right, Right, Right * Test #1: Press Shift+Ctrl+Page_Up to select text to beginning of line. Should hear: "SPEECH OUTPUT: 'This '", "SPEECH OUTPUT: 'selected'" Which we do. * Test #2: Press Shift+Ctrl+Page_Down to select text to end of line Should hear: "SPEECH OUTPUT: 'This is only a test.'" Actually hearing: "This is only a test. unselected * Test #3: Press Shift+Up to select text. Should hear: "SPEECH OUTPUT: '", "This is only a test.'" Actually hearing: "This is only a test. unselected * Test #4: Press Shift+Down to deselect text. Should hear: "SPEECH OUTPUT: '", "This is only a test.'" Actually hearing: "This is only a test. unselected * Test #5: Press Ctrl+Page_Up to beginning of line. Should hear: "SPEECH OUTPUT: 'T'" Actually hearing: "T" unselected I investigated test #2. Before Shift-Control-Page_Down is pressed, the following is selected (the "/" is a Return): 1 2 3 01234567890123456789012345678901234567890 This is a test./This is only a test./ ----- In other words from offset 16 to 20. Caret is at position 16. After Shift-Control-Page_Down is pressed, the following is selected: 1 2 3 01234567890123456789012345678901234567890 This is a test./This is only a test./ --------------- In other words from offset 21 to 36. Caret is at position 36. When we go into onTextSelectionChanged(), and extract the start and end offsets from self.pointOfReference.get("spokenTextRange"), we get 16 and 36. These would have been saved with the call to _saveSpokenTextRange() at the very end of _presentTextAtNewCaretPosition(). These are setup in _presentTextAtNewCaretPosition(), in the section that deals with keyString == "Page_Down" (about line 3307). We have: hasLastPos: True isShiftKey: 1 isControlKey: 4 so we call: [startOffset, endOffset] = self.getOffsetsForPhrase(obj) This method uses self.pointOfReference.get("lastCursorPosition") to get the last cursor position. startOffset is lastPos[1] and endOffset is taken from text.caretOffset. We get: startOffset: 16 endOffset: 36 In all goes downhill from there.
Created attachment 111232 [details] [review] Revision 8. This patch adds in two more special cases to speakTextSelectionState(): Control-Shift-Page_Down: speak "line selected to end from previous cursor position". Control-Shift-Page_Up: speak "line selected from start to previous cursor position". This affects tests #1 and #2 in the Gtk+ regression test role_text_multiline_navigation2.py Test 1 of 12 FAILED: ../keystrokes/gtk-demo//role_text_multiline_navigation2.py:Shift+Ctrl+Page_Up to select text to beginning of line DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=1 SPEECH OUTPUT: 'This ' - SPEECH OUTPUT: 'selected' + SPEECH OUTPUT: 'line selected from start to previous cursor position' [FAILURE WAS UNEXPECTED] Test 2 of 12 FAILED: ../keystrokes/gtk-demo//role_text_multiline_navigation2.py:Shift+Ctrl+Page_Down to select text to end of line DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=21 SPEECH OUTPUT: 'This is only a test.' + SPEECH OUTPUT: 'line selected to end from previous cursor position' [FAILURE WAS UNEXPECTED] which personally I think is better. That test still has three more differences: Test 3 of 12 FAILED: ../keystrokes/gtk-demo//role_text_multiline_navigation2.py:Shift+Up to select text DIFFERENCES FOUND: BRAILLE LINE: 'gtk-demo Application Application Window Frame ScrollPane This is a test. $l' VISIBLE: 'This is a test. $l', cursor=17 SPEECH OUTPUT: ' This is only a test.' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] Test 4 of 12 FAILED: ../keystrokes/gtk-demo//role_text_multiline_navigation2.py:Shift+Down to deselect text DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=21 SPEECH OUTPUT: ' This is only a test.' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] Test 5 of 12 FAILED: ../keystrokes/gtk-demo//role_text_multiline_navigation2.py:Ctrl+Page_Up to beginning of line DIFFERENCES FOUND: BRAILLE LINE: 'This is only a test. $l' VISIBLE: 'This is only a test. $l', cursor=1 SPEECH OUTPUT: 'T' + SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] For tests #3-4, what is happening is we are speaking a complete line of text, but part of it is unselected and part selected. Note that those two tests have always done this. Test #5 is I believe an improvement. Let's discuss this in more detail in the team meeting later today.
I think this one is ready for testing. Adding "[testing required]" to the summary.
I've been testing the last several versions of this patch. I really think this functionality has been much improved. I wonder if it might be a good idea to check it in and file new bugs on any remaining test cases we might find.
Latest patch committed to SVN trunk. Moving to "[pending]". Still to do: 1/ Adjust some of the Gtk+ regression tests to match up with the new output. (Maybe some oowriter and oocalc ones too -- need to check). 2/ Move the newline related problems, from the original 12 issues above, over into bug #387556, where we will deal with them.
Created attachment 111269 [details] [review] Adjust to the Gtk+ role_text_multiline_navigation2.py regression test. Well the good news, is everything else is the same (i.e. known issues and bugs). Patch committed to SVN trunk. This one must be pretty close to done now.