GNOME Bugzilla – Bug 337371
Voluminous output from Orca when volume control slider is visible.
Last modified: 2006-07-25 21:55:31 UTC
As reported on the orca-list mailing list. I think I might now have seen the volume control problem that Al and Ricky reported. I did the following with the mouse. I'm not sure if there is an equivalent keyboard sequence to cause the same result. I had the volume control slider visible on the screen. Accidentally leaving it visible, I gave focus to a gnome-terminal window. Orca spewed out loads of the following messages: ... BRAILLE LINE: 'gnome-panel Application Bottom Expanded Edge Panel Frame Bottom Expanded Edge Panel Panel Volume: 56% EmbeddedComponent Window 56 Slider' VISIBLE: '56 Slider', cursor=1 SPEECH OUTPUT: '56' BRAILLE LINE: 'gnome-panel Application Bottom Expanded Edge Panel Frame Bottom Expanded Edge Panel Panel Volume: 56% EmbeddedComponent Window 56 Slider' VISIBLE: '56 Slider', cursor=1 SPEECH OUTPUT: '56' BRAILLE LINE: 'gnome-panel Application Bottom Expanded Edge Panel Frame Bottom Expanded Edge Panel Panel Volume: 56% EmbeddedComponent Window 56 Slider' VISIBLE: '56 Slider', cursor=1 SPEECH OUTPUT: '56' BRAILLE LINE: 'gnome-panel Application Bottom Expanded Edge Panel Frame Bottom Expanded Edge Panel Panel Volume: 56% EmbeddedComponent Window 56 Slider' VISIBLE: '56 Slider', cursor=1 SPEECH OUTPUT: '56' ... (Note that this is with no changes to the volume control being attempted.) There's something bogus going on there. Opening this bug so we can track it.
Using Orca from CVS HEAD this morning (6th April 2006), I'm unable to reproduce this. I wonder whether the recent changes from Will have made any difference here.
I'm not sure what I could have done to make this change, but I'm happy to take credit for it. :-) Seriously, though, when running into things such as this we should investigate in more detail the stream of events that are causing these things to be output repeatedly. It might be that we are indeed getting duplicate events, and maybe we need to be smarter in Orca to gracefully handle things like that (e.g., don't output again if nothing really changed).
Created attachment 63156 [details] Debug output for this problem. I managed to recreate this again, so I went back and turned on full debugging and saved the output to a file (attached). I recreated this with the mouse, so I'm not sure it's a totally valid accessibility scenerio though. I clicked on the volume control applet in the gnome panel, then dragged the slider to a new position. It then spoke "71" (the new slider value) numerous times. I could understand it if it spoke all the intermediate value (from the old position to the new position), but repeating "71" numerous time does seem bogus.
This debug output definitely helps. It looks like the slider is issuing multiple value-changed events for the same change, and Orca is just happily reporting this regardles if the value changed or not. If this is the case, I'd argue that stupid toolkit behavior is a bug to be filed with the toolkit, but also that Orca needs to work better in the face of stupid toolkit behavior. The first thing to do here is dig in deeper to see just what value is changing - maybe the toolkit is indeed issuing events for different values changing on the same component and we're assuming it is just one value (the slider position). Not sure how we could detect that. The other thing is that we might need to dig into a way to cache the old value and not do anything if the value really didn't change.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
I tested this again with Orca from GNOME CVS HEAD and I don't get the voluminous output, but it also don't get any output unless the slider has focus. I can give the slider focus by pressing Ctrl+down_arrow. When I then adjust the volume, I hear changes and I hear them only once. BUT... I can finally reproduce the voluminous output by clicking on the volume slider and then clicking on a terminal window. I'll look into this.
Well...my fix for bug 342303 should have gotten rid of this (I hope), but the problem still remains where speech can be queued up over and over for the same object when its value changed (e.g., try sliding the slider with the mouse and you can get similar voluminous output). I'll open a new meta bug for this, as I think some of the other bug reports (e.g., bug 341388, bug 341406, bug 334894, bug 323063) might be related to this. The ultimate thing seems to be that we need to introduce a queueing mechanism for speech.
*** This bug has been marked as a duplicate of 334894 ***