See also http://www.openoffice.org/issues/show_bug.cgi?id=87408

This is a dup of: http://www.openoffice.org/issues/show_bug.cgi?id=79701

I can confirm that this is fixed in Impress for OOo dev 3.0 m24(build:9329).

And for the most part, we're already doing the right thing.  (Yea!) However, I did notice that we stop speaking the contents of the layout pane after arrowing to the desired layout and then inserting a slide via the context menu.  I'm not sure if it's our bug, a case we're not handling, or YAOOB. 

It has a feel similar to those bugs where we stop speaking everything as soon as the view is changed.  Those other bugs are waiting to be confirmed but don't yet seem fixed in the current public build. Maybe this issue will just go away. :-)

Assigning this one to me for further investigation.  Lowering the severity to normal because:

* we can now access the impress panes via the keyboard

* the common thing to do after inserting a slide is to move to that
  slide and add text/object (i.e. rather than arrowing around some
  more).

* we have an interim work around: If Orca stops speaking, Tab once
  and then Shift+Tab back and we start speaking again. 

(I'm not saying that's acceptable; merely that it's no longer "severe").

Created attachment 116444 [details] [review]
hack to address the issue

Just took a look. We are getting object:active-descendant-changed events before and after. However before inserting the slide via the context menu, the list has state focused. After, it does not (YAOOB). As a result, onActiveDescendantChanged() takes one look at the non-focused list and immediately returns.

What is interesting (and part of the YAOOB) is that under these conditions, the list lacks STATE_FOCUSABLE as well.  So, do we:

1. File the YAOOB and block this one again?

2. Add a check to see if the object whose active descendant changed is focusable in addition to focused and only return if the former is True but the latter is False?

3. All of the above

This patch does #2 and solves the problem. Haven't regression tested it yet. Will, thoughts?

(In reply to comment #4)
> Will, thoughts?
> 

I'm not sure I'm comfortable with this.  Prior to the patch, the code effectively ignores all descendant changed events for objects that don't have focus:

-        if not event.source.getState().contains(pyatspi.STATE_FOCUSED):

With the patch, it seems as though we have the potential to treat the object from active descendant changes for any UNFOCUSABLE object (i.e., lacks STATE_FOCUSABLE) as the locus of focus:

+        state = event.source.getState()
+        if state.contains(pyatspi.STATE_FOCUSABLE) \
+           and not state.contains(pyatspi.STATE_FOCUSED):
             return

Having said that, I'm not sure how we could get active descendant changed events for unfocusable objects that manage their descendants.  But, I'm still not sure I'm fully comfortable with it. So...perhaps the following?

1) It does seem to be YAOOB to be filed.
2) Create an onActiveDescendantChanged method in scripts/soffice/script.py that basically does the same thing:

    def onActiveDescendantChanged(self, event):
        """Called when an object who manages its own descendants detects a
        change in one of its children.

        Arguments:
        - event: the Event
        """

        if state.contains(pyatspi.STATE_FOCUSABLE) \
           and not state.contains(pyatspi.STATE_FOCUSED):
            return
        else:
            default.Script.onActiveDescendantChanged(self, event)
            return

Still seems kind of strange to me, though it seems like it should work in the presence/absence of the YAOOB.

Created attachment 117331 [details] [review]
revision 2

Thanks Will.

>         if state.contains(pyatspi.STATE_FOCUSABLE) \
>            and not state.contains(pyatspi.STATE_FOCUSED):
>             return
>         else:
>             default.Script.onActiveDescendantChanged(self, event)
>             return
> 

I might just be really tired, but won't the result of the above be the same behavior we're seeing now?  I apologize for not being clear before. The problem is that after inserting a slide via the context/pop-up menu, the list issuing the object:active-descendant-changed events lacks both STATE_FOCUSABLE and STATE_FOCUSED. The default script's onActiveDescendantChanged() discards events from objects which lack STATE_FOCUSED....

This patch creates a soffice-specific onActiveDescendantChanged() as suggested, but attempts to handle the goofiness itself. I added a partial hierarchy check in the hopes of isolating this case (and those similar to it). Seems to work and is pylinted. Still need to run the regression tests.

I have opened http://www.openoffice.org/issues/show_bug.cgi?id=93083 for the a11y issue at hand.  In addition, in testing this patch I noticed that sometimes you can move to a layout and tell Impress to insert a slide *of that layout* but Impress inserts a slide of a different layout (that of the selected slide). That has nothing to do with us (i.e. it's YAOOB and occurs without Orca running), but might pose some confusion when testing this patch. So I figured I'd mention it. I opened http://www.openoffice.org/issues/show_bug.cgi?id=93082 for that problem.

Thanks - this is much more conservative.  Please commit assuming we can get the regression tests worked out.

Thanks Will.  Now that the regression tests are getting back to being in shape with OOo 3.0, I can confirm that this patch does not introduce any regressions. :-)  Patch committed to trunk. Moving to pending.

Closing as FIXED per Will.