Reassigned to KLA

Hi Daniel, 
one for you.
kla

taking over

set target OOo 3.0

accepted

When the ScAccessibleEditObject gets or loses the focus, it now
notifies a state-changed:focused event. This causes Orca to read
the labels 'Left Area', 'Center Area' or 'Right Area' when
pressing TAB or SHIFT-TAB to move the focus.

The problem, that initially 'Left Area' is nor read when
opening the dialog remains. See OBR's mail below for
possible solutions.

In addition I changed the accessible role of the
ScAccessibleEditObject to TEXT_FRAME and added the
accessible state SENSITIVE.

-------------------------------------------------------------------

Hi Rich & Will

Thomas and I have looked into
http://www.openoffice.org/issues/show_bug.cgi?id=86112 and we think this might
be a general problem in OOo. Here is how things work today:


scenario 1:

- the object that receives focus tries to send state-changed:focused, but no
listeners from the OOo ATK bridge have been attached yet.

- the OOo ATK bridge receives a VCL focus event and sends a "focus" event either
for the VCL control itself or the children with the a11y focus (e.g. a paragraph
object).

- Since listeners are attached now, state-changed events will be passed to ATK
from there on


scenario 2:

step one and two of scenario 1 are reversed, so that there already is a listener
attached to the object gaining focus and the initial state-changed:focused will
make it to orca.


We believe issue 86112 is due to scenario 1. To fix it, the bridge could send a
synthetic state-changed:focused when it creates a wrapper object which has the
focused state in its state set, but this might leave to a duplicate
state-changed:focused event in scenario 2.

Another potential solution might be to let the bridge emit a "focus" events for
VCL control & the focused child, but as focus events are collected until idle,
this one might not reach orca.

Both potential solutions would affect nearly newly opened windows.

A third potential solution might be to use a dedicated role for text containers,
which tells orca to speak the parent object as well.

What do you think ?

Regards,
Oliver 

Thanks for looking into this bug.  As background, the typical runtime scenario
is that Orca will be running prior to OOo.  As a result, Orca will have
requested listeners for focus events.

Also, to make sure I understand things correctly, the majority of this bug has
been fixed.  It's now just down to how to get the appropriate information to
Orca so it can make the "Left Area" presentation when the dialog first appears.
 Is that correct?

>scenario 1:
>
>- the object that receives focus tries to send state-changed:focused, 
>but no listeners from the OOo ATK bridge have been attached yet.
>
>- the OOo ATK bridge receives a VCL focus event and sends a "focus" 
>event either for the VCL control itself or the children with the a11y
>focus (e.g. a paragraph object).
>
>- Since listeners are attached now, state-changed events will be passed 
>to ATK from there on

If Orca is running prior to OOo, would this scenario be realistic?

>scenario 2:
>
>step one and two of scenario 1 are reversed, so that there already is 
>a listener attached to the object gaining focus and the initial 
>state-changed:focused will make it to orca.
>
>We believe issue 86112 is due to scenario 1. To fix it, the bridge 
>could send a synthetic state-changed:focused when it creates a wrapper
>object which has the focused state in its state set, but this might
>leave to a duplicate state-changed:focused event in scenario 2.

Orca has defensive code in it to handle duplicate focus events from objects, so
it might be able to deal well with the proposed fix.

To make sure I understand what you're describing, however, the object is created
with the focused state set and as a result, there's no chance of this object
emitting a focus event?  If so, this answers my question above and it seems like
a potential bug in the OOo implementation:  if an object gets focus, a focus
event should be emitted for it.

>Another potential solution might be to let the bridge emit a "focus"
>events for VCL control & the focused child, but as focus events are 
>collected until idle, this one might not reach orca.

Just as a quick question to make sure I understand the vernacular, what is a VCL
control and how does it relate to an ATK object?  Is it that the VCL control is
OOo's equivalent of a GTK+ control and OOo has something like GAIL to create ATK
objects?  I also want to be sure I understand how the term "bridge" is being
used here.  I don't believe you are referring to the ATK bridge, but I'm not sure.

>A third potential solution might be to use a dedicated role for text
>containers, which tells orca to speak the parent object as well.

I'm not sure how this would work.  What would the object and event models be for
this dedicated role?  In addition, are you proposing a new AT-SPI role type, or
would you use an existing one?

Thanks!

Yes, VCL controls are the OOo equivalent to GTK+ controls, but not all
accessible objects are VCL controls (e.g. paragraphs are not). OOo also has
something like GAIL, but it doesn't implement any ATK APIs, but UNO
Accessibility APIs instead.

The OOo ATK objects are wrappers created by what we call the OOo <-> ATK bridge,
which listens on global VCL events to create those wrapper objects on demand
(e.g. on focus events). It is not related to the atk-bridge gtk+ module.

Like in Java, there is no global accessibility event queue, so it always
requires an existing ATK wrapper object to pass any events to orca. So scenario
1 is realistic even if orca is already running as our bridge might not have
created the wrapper object yet.

Solution 1 would check for a FOCUSED state at the time the ATK wrapper object
gets created and emit the state-changed event if set. As mentioned earlier, this
might lead to duplicate state-changed events in scenario 2.

Solution 2 will send an additional "focus:" event eventually (might not make it
to orca when OOo is busy).

For solution 3 I would prefer an existing role, but that would basically be up
to you.

>Solution 1 would check for a FOCUSED state at the time the ATK wrapper 
>object gets created and emit the state-changed event if set. As mentioned
>earlier, this might lead to duplicate state-changed events in scenario 2.

At the time this happens, would the object be visible/showing when this event is
issued and would the widget hierarchy be complete (e.g., if we traced upwards
from the object, would we end up at the OOo application)?  If not, this probably
is not a good solution.  :-(  If so, however, it might be a good thing.  :-)

>Solution 2 will send an additional "focus:" event eventually (might not 
>make it to orca when OOo is busy).

In this scenario, would there occur the possibility that some other object
grabbed focus before the additional focus event made it to Orca, and thus
resulting in Orca forming an incorrect view of the world?

> At the time this happens, would the object be visible/showing when this event
> is issued 

Yes. Only the wrapper object has just been created at this time, the wrapped
object exists for some time already and surely will have visible/showing when
focused.

> and would the widget hierarchy be complete (e.g., if we traced upwards
> from the object, would we end up at the OOo application)?  

When a ATK wrapper object gets created, not yet existing wrappers for all parent
objects are created first.

> In this scenario, would there occur the possibility that some other object
> grabbed focus before the additional focus event made it to Orca, and thus
> resulting in Orca forming an incorrect view of the world?

OOo send "focus:" events only for the last object that claims to have focus
while busy. So the in the scenario you describe, orca won't get the additional
event at all.

However, I should state here that object:state-changed events are not going
through any "on idle" queuing, so orca gets intermediate focused state changes
for all objects with existing wrappers.

I'm getting very confused about what's just internal to OOo and what gets
exposed to the assistive technology, so maybe I should express things more in
terms of what the assistive technology needs.

When something gets keyboard focus, we need a focus event for it.  We also
expect the accessible hierarchy to be accurate for the object when we get the
event -- at a minimum, we should be able to ask for an object's parent and that
object's parent and so on all the way up to the top level object.

The solutions that permit this are the desired ones, and it sounds like solution
1 is one that works.  Is that correct?

Now it is my turn to be confused: what you describe should have been always be
the case, even without the fixes Thomas made:

OOo sends a "focus" event for the paragraph in the "Area" control(s). What orca
doesn't get is an intermediate object:state-changed:focused for the first time
the "area" controls are entered.

Solution 1 will give orca the intermediate object:state-changed:focused event
also initially.

However, I wonder why orca relies on intermediate focus events to speak the
label of the text container instead of asking the focused paragraph for its
parent ? A special role (Solution 3) might help orca to ignore the intermediate
events coming later.


 

Hmm...I'm guessing more debugging is needed to see what the event stream is that
Orca is getting. I'm going back to this:

>Also, to make sure I understand things correctly, the majority of 
>this bug has been fixed.  It's now just down to how to get the 
>appropriate information to Orca so it can make the "Left Area" 
>presentation when the dialog first appears. Is that correct?

I'm not sure we really answered that, so I'm going to download the internal
builds and test.

I did some more testing for this specific bug scenario using the
OOo_3.0.0_080620_Solarisx86 build, and I'm seeing that the bug no longer seems
to exist.

I'm not sure if this was due to changes in OOo, pyatspi, Orca's script for OOo,
or something else, but I'm seeing that Orca responds to an initial focus: event
from the paragraph in the "Left area" panel and presents the paragraph and "Left
area" information.

When tabbing to/from the Left/Center/Right area panels, Orca responds to the
first focus-like event it gets, which is a object:state-changed:focused event
for the associated paragraph.  The subsequent redundant, but expected, focus:
event for the same object is basically ignored.

Rich - if there were anything wrong here, we don't let the user know the
paragraph is 'blank' even though the speakBlankLines option is True (same for
the Right area paragraph).  But, that may be an Orca issue and not an OOo issue.

TBE->WILLIEWALKER:

Thanks for your extensive testing. If I interpret your results
correctly, then the question is, if you can remove the
work arounds in your code due to the missing state-changed:focus
events for the area control. If you don't object, I will
set this issue to fixed (due to code freeze).
We can handle any further improvements in our code in
a follow-up issue.

fixed in CWS tbe34

The following files are affected:

sc/source/ui/Accessibility/AccessibleEditObject.cxx  1.17.72.1

WILLIEWALKER->TBE:

Thanks for fixing this.  We're looking into removing the workarounds in our
code.  With your fixes, however, I believe things will work with or without the
presence of the workarounds we have.  Thanks, and yes, we will follow up if we
still notice problems.

Thanks again for your work on this as well as other accessibility bug fixes.

tested with Orca 2.20.2 on SunOS 5.11 sparc

TBE->ES: Please verify in CWS tbe34.

Verified in CWS tbe34

.

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues