GNOME Bugzilla – Bug 519547
gtk-demo/role_label.py regression test #5 produces the wrong results.
Last modified: 2008-06-16 00:55:53 UTC
This is on latest Ubuntu Hardy: EXPECTED: "BUG? - no selection is announced?", ACTUAL: "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 EXPECTED - LOOK FOR BUG? IN EXPECTED RESULTS] Need to determine why no text selection was announced.
This is another bug that is going to be dependent on bug #517127. We are currently not listening for "object:text-selection-changed" events, and therefore don't recognize that the text selection state has changed.
Rich fixed bug #517127 (thanks!), so that frees this one up for investigation.
The problem here is that doing a Shift-Control-Right for text in a label is not setting the endOffset correctly. So no text is spoken and Orca thinks that nothing is selected. In more detail. Steps to reproduce. 1/ Start Orca 2/ Start gtk-demo. Start the "Dialog and Message Boxes" demo. 3/ Press the "Message Dialog" button. 4/ On the alert that is displayed, press Tab to select all the text. 5/ Then press Home to move the cursor to the start of the text. This also unselects it all. 6/ Then press Right to position it at the next character (h). 7/ Press Shift-Control-Right to select the remainder of the word (his). We get the following event: OBJECT EVENT: object:text-caret-moved detail=(4,0) app.name='gtk-demo' name='This message box has been popped up the following number of times:' role='label' state='enabled focusable focused multi line sensitive showing visible' relations='' The onCaretMoved() method in default.py is called. This is turn calls _presentTextAtNewCaretPosition(). That in turn calls the following code: elif (keyString == "Left") or (keyString == "Right"): print "XXX: point E." # 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. # inNewObj = hasLastPos and not self.isSameObject(lastPos[0], obj) if hasLastPos and not inNewObj and isShiftKey and isControlKey: [startOffset, endOffset] = self.getOffsetsForPhrase(obj) self.sayPhrase(obj, startOffset, endOffset) The getOffsetsForPhrase() method gets the end offset with: text = obj.queryText() ... endOffset = text.caretOffset Unfortunately that doesn't seem to work for labels. text.caretOffset is 1 not 4. Will, what's the best way to handle this? Should we be passing the event into getOffsetsForPhrase() and then checking in there to see if the obj's role is ROLE_LABEL and if so, get the end offset from event.detail1? Or is there a better way? Or is there a gail bug here?
Created attachment 112085 [details] Test application I think we might need Li's input here (CC'ing Li). Here's a sample application to run for the following test case: 1) Run the sample app in an xterm (important to do this in an xterm, not a gnome-terminal) 2) Run gtk-demo->Dialog and Message Boxes->Message Dialog 3) Position the caret between the 'T' and 'h' in 'This'. 4) Hit Shift+Control+Right to select the 'his' in 'This'. You'll see this output: object:text-caret-moved(4, 0, None) source: [label | This message box has been popped up the following number of times:] host_application: [application | gtk-demo] text.caretOffset 1 That is, the detail1 of the event tells us the caret moved to 4. But, the caretOffset says it is still at 1. Something seems askew.
Created attachment 112086 [details] Same test app, but which also includes text selection output
Will, should I just file a new gail bug on this problem and block this one against it?
(In reply to comment #6) > Will, should I just file a new gail bug on this problem and block this > one against it? > Let's get Li's insight here first (making sure he is CC'd). I recall him making a comment at one time about odd event vs. caret behavior, but I cannot remember what it was. It may be that this will be very difficult to fix in gail.
I think the problem here is what is "cursor". If the cursor is at position 1, and we press ctrl+shift+right, where is the cursor now, position 1 or 2? If call get_caret_offset, it will return 1, but the "text-caret-moved" signal shows it is 2. We have 2 options here: 1) treat position 1 as the caret, and don't emit "text-caret-moved" signal, Orca can still get "selection-changed" signal. 2) treat position 2 as the caret, emit "text-caret-moved" signal and change the caret to 2, also emit "selection-changed" signal. In my opinion, "selection-changed" should be sufficient. Since Orca doesn't listen to "selection-changed", I guess option 2 is the better solution for Orca?
Created attachment 112190 [details] [review] patch to make cursor_position to the changed bound
Hi Li: (In reply to comment #8) > I think the problem here is what is "cursor". If the cursor is at position 1, > and we press ctrl+shift+right, where is the cursor now, position 1 or 2? If > call get_caret_offset, it will return 1, but the "text-caret-moved" signal > shows it is 2. Exactly -- there's a conflict between what the event is telling us and where the object thinks the caret is. > We have 2 options here: > 1) treat position 1 as the caret, and don't emit "text-caret-moved" signal, > Orca can still get "selection-changed" signal. > 2) treat position 2 as the caret, emit "text-caret-moved" signal and change the > caret to 2, also emit "selection-changed" signal. > > In my opinion, "selection-changed" should be sufficient. Since Orca doesn't > listen to "selection-changed", I guess option 2 is the better solution for > Orca? Option #2 would be a lot better. Conceptually, the user is moving the caret to cause the selection to happen. As an example of this, consider the following: 1) Write "this is a test" and position the caret before the 'i' of "is" 2) Press Shift+Ctrl+Right - "is" is selected 3) Now press Shift+Left - the 's' of "is" is unselected Had the caret remained at the beginning of the "is", the Shift+Left would have selected the 'space' before "is". So...if your patch provides option #2, that's great.
Hi Li. Thanks for doing this. I've just been testing your patch. We have a set of regression tests for Orca using various aspects of gtk-demo. I just ran them all, and the only one that's changed (as might be expected is the one associated with labels). I've included the results below. You'll notice that the BRAILLE line now has the cursor at a different position for most of them. This I believe is correct. And the good news is that the "his" is spoken and announced as selected in test #5. Yea! It also fixes test #9, now speaking "This" "selected". In other words, I think this is a great fix. Will, could you cast your eyes over these differences and make sure they are all good. Thanks! ---- Running /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py starting test application gtk-demo ... Test 1 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label 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=1 + BRAILLE LINE: 'gtk-demo Application Information Alert number of times: $l' + VISIBLE: 'number of times: $l', cursor=17 SPEECH OUTPUT: '' SPEECH OUTPUT: 'This message box has been popped up the following number of times: label' [FAILURE WAS UNEXPECTED] Test 2 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label Where Am I 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 number of times: $l' + VISIBLE: 'number of times: $l', cursor=17 SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' [FAILURE WAS UNEXPECTED] Test 3 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label Extended Where Am I 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=1 + BRAILLE LINE: 'gtk-demo Application Information Alert number of times: $l' + VISIBLE: 'number of times: $l', cursor=17 + BRAILLE LINE: 'gtk-demo Application Information Alert number of times: $l' + VISIBLE: 'number of times: $l', cursor=17 SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' [FAILURE WAS UNEXPECTED] Test 4 of 9 SUCCEEDED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret movement to 'h' 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=5 + SPEECH OUTPUT: 'his' + SPEECH OUTPUT: 'selected' [FAILURE WAS UNEXPECTED] Test 6 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret selection Where Am I 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 ? ^ + VISIBLE: 'This message box has been popped', cursor=5 ? ^ SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' [FAILURE WAS UNEXPECTED] Test 7 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret selection Extended Where Am I 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 ? ^ + VISIBLE: 'This message box has been popped', cursor=5 ? ^ 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 ? ^ + VISIBLE: 'This message box has been popped', cursor=5 ? ^ SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' SPEECH OUTPUT: 'This message box has been popped up the following number of times:' SPEECH OUTPUT: 'selected' SPEECH OUTPUT: 'label' [FAILURE WAS UNEXPECTED] Test 8 of 9 SUCCEEDED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret select 'T' in 'This' Test 9 of 9 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py:This message box label caret select rest of 'This' 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 ? ^ + VISIBLE: 'This message box has been popped', cursor=5 ? ^ - SPEECH OUTPUT: 'T' + SPEECH OUTPUT: 'This' ? +++ SPEECH OUTPUT: 'unselected' [FAILURE WAS UNEXPECTED] SUMMARY: 2 SUCCEEDED and 7 FAILED (7 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py
(In reply to comment #11) > In other words, I think this is a great fix. I agree. Thanks Li! If you can get this into GNOME 2.22.3 as well, it would be great. > Will, could you cast your eyes over these differences and make sure > they are all good. They all (e.g., the selection presentation and braille cursor position changes) look good to me. Thanks!
Sure. Please refer to Bug #536927.
Thanks Li. So Will, do you want me to adjust the gtk-demo role_label.py regression test now, or wait until a new Gtk+ tarball comes out or ... ?
(In reply to comment #14) > Thanks Li. So Will, do you want me to adjust the gtk-demo role_label.py > regression test now, or wait until a new Gtk+ tarball comes out or ... ? How about going for it now? Thanks!
Created attachment 112418 [details] [review] Patch to fixup the regression test... ... to match the new results. Patch applied to SVN trunk. Moving to "[pending]".
(In reply to comment #9) > Created an attachment (id=112190) [edit] > patch to make cursor_position to the changed bound > Li - can you please make sure this gets into a GAIL release for GNOME 2.23.x and GNOME 2.22.3?
Hasn't Li's patch been checked into Gtk+/gail as part of bug #536927? Shouldn't that attachment: http://bugzilla.gnome.org/attachment.cgi?id=112190 just be marked as "obsolete"?
(In reply to comment #18) > Hasn't Li's patch been checked into Gtk+/gail as part of bug #536927? > > Shouldn't that attachment: > http://bugzilla.gnome.org/attachment.cgi?id=112190 > just be marked as "obsolete"? Ah..you're right. I was basing my comments off of my surprise that the change was not in gail/trunk. I now remember that gail/trunk is dead since it's been moved to gtk+/trunk/modules/other/gail and gail/branches/gnome-2-22 is the branch for GNOME 2.22. Reclosing.