This is not exactly a clear bug report for people who have no knowledge of the
code. I followed the steps exactly and do not see any bug since the report is
not clear enough to substantiate any happening.

It is obvious that you are talking about something in the OO code, but it should
be visible from the program standpoint. The only difference I found when
arrowing around, is that the layouts on the left side of the task pane had text
describing the layout that was still for arrowing each layout, and on the right
side they would move with the mouse.  Also, when right clicking on a slide to
"Insert Slide" the layout will be the layout of the current slide, instead of
the one you right clicked on. This is easily remedied by left clicking on the
layout you want before right clicking.

This report is pretty clear exactly when you know what it is about
(accessibility). And I know it, that's why it's been assigned to me.

@joaniediggs: not sure how to see or not STATE_FOCUSABLE and STATE_FOCUSED.
Can you give me some hint for accersizer or at-poke?

Created attachment 56686 [details]
Using Accerciser to see STATE_FOCUSABLE is absent

The screenshot I just attached will hopefully help answer the question of how to
verify that STATE_FOCUSABLE is absent event when STATE_FOCUSED is present.  It's
also one of the best (work-related) justifications for having at least a
dual-head box with wide screen monitors. :-)

The trick is that you need to have:

1. Accerciser's Interface viewer visible

2. The Layouts (from Impress) list selected within Accerciser

3. The list of States (in Accerciser's Interface viewer) scrolled so that
'focused' will be visible once you give focus back to Impress

The reason for all of this trickery is that the minute you give focus back to
Accerciser (or anything else for that matter), the Layouts list will not display
STATE_FOCUSED because, presumably, it's no longer focused. :-)

(BTW, if you perform the same trickery after giving focus to something else
within Impress, you should find that anything with STATE_FOCUSED also has
STATE_FOCUSABLE. There just seems to be something about that list which isn't
quite right.)

Created attachment 56687 [details]
Screenshot: Using Accerciser to try to figure out what's going on in general :-)

@es I'm having a harder time finding a way to reproduce the part of this bug
where STATE_FOCUSED goes missing without using Orca. When I use Accerciser as
described earlier and then perform the steps outlined in my original report,
Accerciser continues to display STATE_FOCUSED for the Layouts list. But:

1. When I look at the debugging output from Orca, before getting into the
context/pop-up menu, STATE_FOCUSED is definitely present, and after it
definitely is not. This would make me suspect Orca were it not for:

2. Accerciser in my experience does not 100% of the time update states without
"refreshing" the list. The act of refreshing the list (by moving focus into
Accerciser and choosing another item and/or choosing Refresh from the View menu
and then returning focus to Impress) causes the list to emit a focus: event
which presumably causes it to have STATE_FOCUSED, and then we don't know if it
was officially focused before or not. :-)

So.... Adding Will to the CC list for a sanity check and insight. (Hi Will!) In
the meantime, I started looking at the focus: events emitted by the Layout list
using Accerciser. I get the expected focus: events when:

a. I click in the list and focus was not there before.

b. I'm in the list, get into the File menu, and then press Escape causing focus
to be given back to the list.

c. I leave the list by pressing Control+Shift+Tab and then return to the list by
pressing Control+Tab, Arrowing Down to Layouts and pressing Return.

d. I give focus to the list, then leave Impress by Alt+Tabbing out of it, and
return to Impress by Alt+Tabbing back into it .

i.e. normally the list issues focus: events. In addition, whatever I give focus
to in the cases above also issues focus: events. However, when I perform the
steps in the original report, the two menu items (Apply to Selected Slides and
Insert Slide) issue focus: events as expected, but when focus is ultimately
given back to the Layouts list afterwards, the Layouts list never issues a
focus: event to reclaim focus. Shouldn't it be issuing one? (I think it should.)
Is that the same problem as the bug? (Couldn't tell ya, but it seems like it
might be. :-) Will, thoughts?)

Anyhoo, the previous screenshot illustrates how you can use Accerciser to see
what events we're getting. Given the number of focus: events issued, I narrowed
things down by first selecting the Layouts list in Accerciser and then turning
on event monitoring just for focus events and just for the selected accessible.

Hope this helps! And thanks again for looking into it!

OOo 3.2

@joaniediggs: I try to sum up.... 

I have set Accerciser as shown on your screenshot.
If I understand as it should:
- click on Layout (focus event shown in Accerciser = ok)
- context menu (focus event for the context menu is shown in Accerciser = ok)
- after click in context menu, the focus IS (one can see it) in the layouts but
NO focus event is tracked in Accerciser.

Is that correct?

I couldn't find anywhere STATE_FOCUSED or STATE_FOCUSABLE "as is" in Accerciser.
Should I? Can I? Where?

Ping! :)

@es: Sorry, I was away from work and from Orca and am just now getting caught
up. That said, thanks for the ping as this one had somehow fallen off my radar.

> If I understand as it should:
> - click on Layout (focus event shown in Accerciser = ok)

Your statement is correct and the results are correct/as-expected.

> - context menu (focus event for the context menu is shown in 
> Accerciser = ok)

Your statement is correct and the results are correct/as-expected.

> - after click in context menu, the focus IS (one can see it) in the layouts
> but NO focus event is tracked in Accerciser.

Your statement is correct. But the results are NOT as-expected. When focus is
given/returned to that list, we *should* get a focus event. Usually we do, but
after clicking in the context menu we don't. That's a bug.

> I couldn't find anywhere STATE_FOCUSED or STATE_FOCUSABLE "as is" in
> Accerciser. Should I? Can I? Where?

Part of it involves doing things "just so"; part of it is the bug being
reported. :-) I'm going to err on the side of (way) too much detail in the hopes
of being clear. My apologies.

Take a look at this screenshot:
http://www.openoffice.org/nonav/issues/showattachment.cgi/56686/93083.png

As you can see, it's two different windows. In the top (Accerciser) window, note
that:

1. The "Layouts" list is the selected accessible on the left-hand side of the
window.

2. Immediately to it's right, in the Interface Viewer, there is a list of
states. Amongst the states shown in that list is "focused." (i.e. that's the
answer to where you should look to find the states in Accerciser.) Focused
should be present. *In addition* I would expect to see "focusable" listed right
above it because, after all, if an object has STATE_FOCUSED it is by definition
FOCUSABLE. :-) The lack of "focusable" is a bug.

As for doing things "just so": From your description it sounds as if you found
that lists of states just fine, but did not see "focusable" OR focused. If
so.... Take another look at that screenshot and note that the bottom (Impress)
Window is active -- as can be seen by the title bar colors -- and that one of
the items in the layout list is selected. 

My suspicion is that you made the Accerciser window active. If the Accerciser
window is active, the Impress window is of course not. If the Impress window is
not active, the layout list seems to lose state focused because it surrendered
focus when the window containing it surrendered the same. I guess. <smiles>

As a result, what I do is get my Accerciser window all set up (interface viewer
showing, layouts selected in the list of accessible objects). Then without
covering that window up, I move back to Impress, perform the steps outlined in
the bug, and keep an eye on what is changing in the Accerciser window. 

So.... I hope that clarifies things. If it doesn't, you know where to find me --
and I promise to be responsive this time. :-)

Thanks again for digging into this and pinging me!

@AF: Please have a look.

I can confirm that the FOCUSABLE state is never set for the layout menu, there
is simply no code that does that.  However, there is also no code that sets the
FOCUSED state, which for me is correctly displayed before and after inserting a
new slide for a layout.  Accerciser shows it to be part of the controls state
set and Orca reads the titles of the layouts.

I suspect that the ATK bridge in VCL maintains the FOCUSED state.

The ValueSet control now handles the FOCUSED and FOCUSABLE states explicitly
and, hopefully, correctly.

SVN revision of the file changes is 276214.

@es: Please verify.

Verified in CWS impressaccessibility4

Fixed and integrated => closing now..