Please speak Split button accName

[carolyn]

Toolbar buttons with BTNS_DROPDOWN style have MSAA role: ROLE_SYSTEM_SPLITBUTTON. In Eclipse, we give these buttons an accName, and we allow them to take focus. NVDA is not speaking the accName when one of these split buttons gets focus.

Windows version: probably any, but I am using XP SP3
NVDA version: probably any, but I am using main-3559
Eclipse version: any, but here is the download link for Eclipse 3.6:
 http://download.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/eclipse-SDK-3.6-win32.zip

Steps to see the problem:

• Download and unzip Eclipse
• Run eclipse\eclipse.exe and type enter to select the default workspace
• Select Go to the Workbench (in the Welcome screen)
• You should hear "Tree View". You are in the Eclipse "Package Explorer".
• Now type ctrl+TAB a couple of times. You should be in the main Eclipse toolbar. There are several "split buttons" in this toolbar, and their accName can be seen in inspect32.exe.

I have heard split button names spoken in other screen readers. But NVDA does not speak their name.

[jteh]

NVDA definitely doesn't ignore the accName for split buttons. However, I'm getting some odd results here.

I tested with Eclipse I20100601-0800, which is a bit old but not very. :) The first time i tested, I got a whole load of buttons with no names. I inspected the MSAA objects directly using NVDA's Python console and accName() was definitely returning NULL. I ran Narrator and also got no button names.

However, I then restarted Eclipse and the button names were speaking properly. To be sure, I reverted to an earlier snapshot of my vm without Eclipse installed and installed it again. Now I can't reproduce the case where there are no button names, despite using a clean Eclipse install.

I honestly have no idea what's going on here. I can tell you that we don't ignore accName() for split buttons.

Leaving open until we know what's going on here.

[carolyn]

I was seeing odd behavior, too. If I hovered over a split button with the mouse, then the MSAA name was always correct, but if I navigated there with the keyboard, MSAA did not even ask the split button for its accName, and so it reported that there was no name. I finally figured out that MSAA was sending get_accName to the split button's *child* (the drop-down button). Wild.

Anyhow, what I have done is to hook get_accName on the drop-down button child, and now MSAA, and consequently NVDA, happily speak split button names all the time.

So you can close this ticket - I have made the change on my side.
It will be available in Eclipse 3.6.1 and Eclipse 3.7 builds as of tomorrow (20100826).

[jteh]

Closing, but I'm curious:

MSAA doesn't really send queries like that itself. NVDA sends MSAA queries like get_accName based on the object that has the focus; i.e. fired the last focus event. If you're seeing queries to the split button's child, this suggests that you're firing a focus event for the split button's child instead of the split button itself. Although your accName fix works, I'd argue that this is the deeper problem.

[carolyn]

Ah, that makes sense. In fact, I am not explicitly firing focus events anywhere in the tool bar - it's all native win32 tool buttons. So since we are using win32 split buttons, they are doing whatever win32 makes them do when the user tabs to them (i.e. they must be firing a focus event for the split button's child).
I guess when I said "MSAA", I was actually referring to inspect32. <grin>

Anyhow, I have a feeling that if I explicitly fired a focus event for the split button rather than the drop-down button child, something else somewhere would be messed up, because the OS still thinks that the thing that really has focus is the drop-down button child. So it is probably best to leave in the accName hack that I have, rather than open a whole new can of worms <grin>.

Thanks for the explanation, Jamie! I often forget to think of things from the client-side perspective. ;)