Created attachment 106510 [details]
Orca debug when running synchronously.

Created attachment 106511 [details]
Orca debug when running asynchronously.

When I press Down when focus is on the Hue spin button
with an initial value of 240:

Asynchronously it speaks:
SPEECH OUTPUT: '240'
because of an "object:text-changed:insert" event, followed by:
SPEECH OUTPUT: '239'
because of an "object:text-caret-moved" event.

Synchronously it speaks:
SPEECH OUTPUT: '240'
because of an "object:text-changed:insert" event, followed by:
SPEECH OUTPUT: '240'
because of an "object:text-caret-moved" event.

Need to determine why these are different.

Well this is interesting. 

With the "object:text-changed:insert" event, the braille display 
gets the correct value:

BRAILLE LINE:  'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 239 $l'
     VISIBLE:  'Hue: 239 $l', cursor=6

but the speech gets it wrong (240).

SPEECH OUTPUT: '240'

Braille.
--------
In onTextInserted() in default.py, to get the braille line we call

        self.updateBraille(event.source)

(at line 3336 in default.py). For the spin button we further call
_getBrailleRegionsForSpinButton() in braillegenerator.py
which in turn calls _getBrailleRegionsForText().

That method calls:

        textRegion = braille.Text(obj,
                                  self._script.getDisplayedLabel(obj),
                                  " $l")

(at line 801 in braillegenerator.py). In the Text class in braille.py,
the __init__() method calls:

            [string, self.caretOffset, self.lineOffset] = \
                 orca_state.activeScript.getTextLineAtCaret(self.accessible)

(at line 467 in braille.py). This returns a string of "239".

Speech.
-------
In onTextInserted() in default.py, to get the speech for the value
of the spin button, we call

        text = event.any_data

        # If this is a spin button, then speak the text and return.
        #
        if event.source.getRole() == pyatspi.ROLE_SPIN_BUTTON:
            speech.speak(text)
            return

(at line 3338 in default.py). The value of the text variable is "240".

Will, should we be doing something on the speech side equivalent to what we
are doing on the braille side?

(In reply to comment #3)
> Well this is interesting. 
> 
> With the "object:text-changed:insert" event, the braille display 
> gets the correct value:
...
> but the speech gets it wrong (240).
...
> Braille.
...
>                  orca_state.activeScript.getTextLineAtCaret(self.accessible)
...
> Speech.
>         text = event.any_data
...
> Will, should we be doing something on the speech side equivalent to what we
> are doing on the braille side?

OK, so the difference seems to be that braille makes a round trip to get the text and speech uses event.any_data.  The strange thing to me is why event.any_data seemingly seems to be different from the current state of the text.  Does this seem like a potential gail bug to you?  Can you dig more to verify that the event.any_data of the text inserted event seems to be the old value rather than the new value?

In addition, I guess a perfectly reasonable workaround would be to use getTextLineAtCaret for speech.

> Does this seem like a potential gail bug to you?

I'm not sure. :-(

> Can you dig more to verify that the event.any_data of the 
> text inserted event seems to be the old value rather than 
> the new value?

Yes, it's the old value.

> In addition, I guess a perfectly reasonable workaround would be to use
> getTextLineAtCaret for speech.

Okay, I'll try to generate a patch that does that.

Thanks.

(In reply to comment #5)
> > Does this seem like a potential gail bug to you?
> 
> I'm not sure. :-(

It's never been clear to me what's a gail bug versus a gtk+ bug, but fwiw you can reproduce the problem in Accerciser's event monitor.  :-) Seems that if text is selected when you Up/Down Arrow, the any_data is wrong for the object:text-changed:insert event.  If text isn't selected, the any_data seems to be correct.

Thanks Joanie. Accerciser just hangs the desktop for me when I try to
Control-Alt-A to expand the component for the Hue spin button.

I've open gtk+/gail bug #520395 for this problem. I won't block it yet as
we can probably work around it using the equivalent of:

orca_state.activeScript.getTextLineAtCaret(self.accessible)

Created attachment 106576 [details] [review]
Patch that I thought should have fixed the problem.

This patch works in asynchronous mode, i.e. speaks:

SPEECH OUTPUT: '239'
because of an "object:text-changed:insert" event, but doesn't
work in synchronous mode: still speaks:
SPEECH OUTPUT: '240'.

I double checked the braille output for the "object:text-changed:insert" event
when running synchronously and it was wrong (without the patch) and is still
wrong (with the patch):

BRAILLE LINE:  'gtk-demo Application Changing color ColorChooser ColorChooser Hue: 240 $l'
     VISIBLE:  'Hue: 240 $l', cursor=6

So the above patch will fix up the speech when Orca is running
asynchronously for the "object:text-changed:insert" event and the
"object:text-caret-moved" event ("239" each time),  but not
give the correct result in the regression test when running
synchronously. Better to have the right value twice then the
incorrect value twice.

So we have a few choices here:
1/ Apply this patch to improve the asynchronous (normal Orca)
   experience.
2/ Wait until the under lying gtk+/gail bug is fixed and block this
   bug against.
3/ Adjust the regression test to output "KNOWN ISSUE:".
4/ All of the above.
5/ Some of the above.

Thoughts?

With or without the patch, I seem to get double-speech:

1. object:text-changed:delete
2. object:text-changed:insert

Without the patch I hear the old value and then the correct value; with the patch I hear the correct value (but twice).

(In reply to comment #8)
> synchronously. Better to have the right value twice then the
> incorrect value twice.

Oops, I guess I should read more closely.  You already knew about the double speech.... Sorry Rich.

Still, I'm wondering if we can detect the condition in the object:text-changed:delete event as something we don't want to speak? 

Created attachment 106813 [details] [review]
Fix up regression test #4 as KNOWN ISSUE.

Two patches committed to SVN trunk. Closing as FIXED.

This means that it speaks the correct result (twice!)
when running asynchronously, and the incorrect result (twice!)
when running synchronously.

This also means that regression test #4 is now considered a
KNOWN ISSUE.