GNOME Bugzilla – Bug 523238
gtk-demo role_text_multiline_navigation.py regression tests 89, 90, 91 and 93 produce the wrong results.
Last modified: 2008-04-24 17:41:50 UTC
Test 89 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Ctrl+Page_Down to select text to end of line EXPECTED: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=4", "SPEECH OUTPUT: 'Thi'", "SPEECH OUTPUT: 'unselected'", ACTUAL: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=10", "SPEECH OUTPUT: 'This is o'", "SPEECH OUTPUT: 'unselected'", Braille cursor position and speech out put are different. Test 90 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Up to select text EXPECTED: "BRAILLE LINE: 'gtk-demo Application Application Window Frame ScrollPane a test. $l'", " VISIBLE: ' a test. $l', cursor=5", "SPEECH OUTPUT: 'est. ", "Thi'", "SPEECH OUTPUT: 'selected'", ACTUAL: "BRAILLE LINE: 'gtk-demo Application Application Window Frame ScrollPane a test. $l'", " VISIBLE: ' a test. $l', cursor=10", "SPEECH OUTPUT: '", "This is o'", "SPEECH OUTPUT: 'selected'", Same again. Test 91 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Down to deselect text EXPECTED: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=4", "SPEECH OUTPUT: 'est. ", "Thi'", "SPEECH OUTPUT: 'unselected'", ACTUAL: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=10", "SPEECH OUTPUT: '", "This is o'", "SPEECH OUTPUT: 'unselected'", And again. Test 93 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Ctrl+Page_Down to end of line EXPECTED: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=4", "SPEECH OUTPUT: 'This is only '", ACTUAL: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=10", "SPEECH OUTPUT: 'This is only '", Braille cursor position is different.
Comment from Joanie: "Confirmed."
I've been trying to just isolated test #89 here, to see why it's giving unexpected output. This is without running Orca. * Started gtk-demo and the "Application main window" demo. * Typed in the following text, between the two "CUT HERE" lines: ------CUT HERE------ This is a test. This is only a test. PLEASE DO NOT PANIC. I'm just going to keep on typing. Then, I'm going to type some more. I just do not know when to quit typing. I think I might have spent too much time in the lab and not enough time in the wild. ------CUT HERE------ * Positioned the text cursor to the right of the first space on the second line. I.e.: This |is only a test. * Typed Control-Shift-Page_Up This selects the "This " at the beginning of the second line. * Then typed Control-Shift-Page_Down After this, the "is o" on that line is the only thing selected. Is this the expected behavior? Because if it is, I haven't worked out the rationale for it.
> * Typed Control-Shift-Page_Up > This selects the "This " at the beginning of the second line. Confirmed. Just to be sure, do you mean "Having performed the above step and not pressed any other keys, you:" > * Then typed Control-Shift-Page_Down ? If so, I'm seeing something different. At this point "This " becomes unselected and "is only a test." becomes selected. > Is this the expected behavior? Because if it is, I haven't worked > out the rationale for it. What you're seeing is unexpected. I wonder why you're seeing it (or why I'm not).
I think it's to do with the size of the window. If I expand the application window so that all the text on all the lines is visible, see what you see. If I go with the initial width and height of the window, it shows about 4 lines and about "I think I might have spent to" of the third from last line. When i type Control-Shift-Page_Down, as well as seeing just "is o" selected, it also scrolls right so that "nly a test." is left most and visible. This feels like broken Gtk+ behavior to me.
Weird. Okay, now I can reproduce it. I dunno why I couldn't before. But now that I can, I would agree this is is broken/a bug.
.... Or a goofy feature. http://library.gnome.org/users/gnome-access-guide/latest/keynav-23.html.en#keynav-28 In particular: > Ctrl+Page Up Position the cursor one view width to the left. > Ctrl+Page Down Position the cursor one view width to the right. Therefore, I think we can solve the problem stated in the bug (regression tests, wrong results) by using alternative commands to accomplish what is being tested. For instance, Shift+End is the "traditional" command to select text from the present location to the end of the line (test 89).
(In reply to comment #6) > .... Or a goofy feature. > > http://library.gnome.org/users/gnome-access-guide/latest/keynav-23.html.en#keynav-28 > > In particular: > > > Ctrl+Page Up Position the cursor one view width to the left. > > Ctrl+Page Down Position the cursor one view width to the right. > > Therefore, I think we can solve the problem stated in the bug (regression > tests, wrong results) by using alternative commands to accomplish what is being > tested. For instance, Shift+End is the "traditional" command to select text > from the present location to the end of the line (test 89). I would tend to agree, but I think I remember explicitly putting these tests in there to provide better coverage for the logic in default.py:_presentTextAtNewCaretPosition (look for "Page_Up" and "Page_Down" in that method). But, I do agree we probably can accomplish the test by doing something else. One thing we might do is move these to a new *.py test which creates a window with only the following two lines in it and then conducts the tests: This is a test. This is only a test. With this, the text should be smaller than the window and we won't have to deal with the odd "one view width" behavior.
Created attachment 108436 [details] [review] Revision #1. I've moved the last 12 tests out of role_text_multiline_navigation.py into a new test file (using two lines of text for the tests). Patch not committed yet. What I've done is set the EXPECTED output to what is being current brailled and spoken, so Mike, I need you to confirm if that is the expected results. Thanks.
This seems correct to me.
(In reply to comment #8) > Created an attachment (id=108436) [edit] > Revision #1. > > I've moved the last 12 tests out of role_text_multiline_navigation.py into > a new test file (using two lines of text for the tests). Thanks! I noticed this one thing, and I apologize for it since I suspect I was the source: +"""Test of backspacing over characters in gedit. +""" Since your patch edits both files, can you edit the comment at the top to better reflect what the test is doing? For example, "general text navigation using caret navigation and flat review techniques" or something like that?
> Since your patch edits both files, can you edit the comment at the top to > better reflect what the test is doing? For example, "general text navigation > using caret navigation and flat review techniques" or something like that? Done. (Adjusted) patch committed to SVN trunk. Closing as FIXED. Thanks.
I think I must have just forgotten to close this one. The patch has already been committed. Closing now.