Re: [orca-list] orca 3.11 and java applications

[Joanmarie Diggs <jdiggs igalia com>]

Hey José.

> It seems I managed to get the menu bar to be read by orca, although I am
> not sure if done in the best way.

Congrats!

> The problem now is that the menus are not read when I press down arrow.

Ok, taking a look at your output...

> Since state does not contains pyatspi.STATE_FOCUSED, the process of this
> event is terminated without produce the expected result.
>
> Am I correct?

You are correct. And that's not a bug in the default script. If a
toolkit's accessibility support is well-implemented, it is to be
expected that by the time we process an event, the state that was true
at the time of the event is no longer true due to a subsequent event.
And if the thing which claimed focus no longer has focus, we don't want
to present that it has focus.

I'd ask you what instead claimed focus, but I suspect you already did
that. Besides, and perhaps more importantly, looking at your debug
output, that menu item doesn't even claim state focusable, so my guess
is that nothing claimed to have stolen focus from the menu item.
Instead, it's a bug on the Java side: Things which emit
state-changed:focused events are expected to have state focusable;
things which are not focusable should not emit state-changed:focused events.

Having said that.... In containers that have selectable children, we
expect selection-related events. In the case of a menu, I would expect
to see the following:

* object:selection-changed (sadly all event details are 0) emitted by
  the parent (in this case that would be the File menu)
* object:state-changed:selected (event.detail1 a boolean) emitted by
  the child which just became selected or unselected (in this case that
  would be the New File menu item)

Orca also expects to see the above. Is Java giving us the above?

Thanks again!
--joanie