GNOME Bugzilla – Bug 519553
gtk-demo/role_radio_button.py regression test #3 produces the wrong results.
Last modified: 2008-03-26 00:12:10 UTC
This is on latest Ubuntu Hardy: EXPECTED: "BUG? - 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'", ACTUAL: "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 BUG? IN EXPECTED RESULTS] Test 5 of 5 FAILED: /home/jd/orca/test/keystrokes/gtk-demo/role_radio_button.py:All radio button EXPECTED: "BUG? - 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'", ACTUAL: "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 BUG? IN EXPECTED RESULTS] We need to determine why the radio button isn't being presented as selected. We also seem to be getting actual results for the "All" radio button and not the "Range" radio button.
Created attachment 106560 [details] Orca debug when running asynchronously.
Created attachment 106561 [details] Orca debug when running synchronously. Commentary to follow.
This is another synchronous vs asynchronous problem. When we Down arrow to the Range radio button, we get a "object:state-changed:focused" event. This is followed by two "object:state-changed:checked" events. One with a detail of (0,0) for the All radio button and the other with a detail of (1,0) for the Range button. When we are running asynchronously, we speak: SPEECH OUTPUT: '' SPEECH OUTPUT: 'Range selected radio button' and when we run synchronously, we speak: SPEECH OUTPUT: '' SPEECH OUTPUT: 'Range not selected radio button' Note also that the braille line is incorrect in syncronous mode: Asynch: ------- BRAILLE LINE: 'gtk-demo Application Print Dialog TabList General Page Print Pages Filler &=y Range RadioButton' VISIBLE: '&=y Range RadioButton', cursor=1 Synch: ------ BRAILLE LINE: 'gtk-demo Application Print Dialog TabList General Page Print Pages Filler & y Range RadioButton' VISIBLE: '& y Range RadioButton', cursor=1 Will, what approach should be taken to fix this? Should the onStateChanged() method in default.py be speaking/brailling this? Currently it does nothing (presumably because the new locus of focus is the same as the old one).
*** Bug 519555 has been marked as a duplicate of this bug. ***
Fix will need to correct regression tests #3 and #5.
(In reply to comment #3) > Will, what approach should be taken to fix this? I'm not sure. If we could predict that the state would be changing when the object got focus, we might be able to handle this in several different ways (e.g., don't set the locus of focus until the selection happens, don't speak the selection state until it changes, etc.). But, I'm not sure we can predict this. The disconcerting about this predicament is that it definitely represents a potential timing problem where Orca could potentially output incorrect information even when running asynchronously. So, this merits some more thought, but I don't have any great ideas right now. I'd definitely love to hear what you come up with, though.
Created attachment 106810 [details] [review] Patch to fix the problem. After discussing it with Will, we are going with adjust the stopRecording() method in util.py to look for assertion results that start with "KNOWN ISSUE". If found, then they are expected failures (was originally like this for "BUG?" assertions). The regression tests #3 and #5 have been updated to start with "KNOWN ISSUE".
Patch committed to SVN trunk. Closing as FIXED.
Will was asking today about radio buttons having the wrong state. This is the bug containing the regression test that shows this problem (see comment #3). We are currently working around this with a "KNOWN ISSUE".