Bug 25535 – [GTK] object:state-changed:checked events missing for radio buttons and checkboxes

• Component: Accessibility
• Status: RESOLVED FIXED

[Joanmarie Diggs]

Steps to reproduce:

1. Open the (to be) attached test case.

2. In Accerciser, select WebKit (or Epiphany) in the list of accessibles in the left-hand pane. In the right-hand pane, switch to the Event Monitor. Select "Selected application" as the source and object->state-changed as the event type to monitor.

3. With event monitoring enabled, return focus to WebKit (or Epiphany). Toggle the state of the checkboxes and radio buttons.

Expected results: Each time the state is toggled, an object:state-changed:checked event would be emitted with detail1 indicating the state (0 == unchecked; 1 == checked).

Actual results: no object:state-changed:checked events are emitted.

[Joanmarie Diggs]

Created attachment 29984 [details]
aforementioned test case

[Xan Lopez]

Created attachment 31410 [details]
statechangedchecked.patch

Implement the signal.

I'm not sure if adding the AX notification stuff in HTMLInputElement is OK, but it seemed like the most sensible place I could find. Suggestions welcome!

[Eric Seidel (no email)]

CCing Jon so he sees this go by.

[Holger Freyther]

I think this is a great change. On the down side no one in WebCore/html is doing something like this. You should really try to grab someone on irc to get this in.

[Maciej Stachowiak]

Comment on attachment 31410 [details]
statechangedchecked.patch

Accessibility notifications right now are posted from all over the code. It might be good to rationalize them (maybe they should all come from the render tree), but for now this seems like a sensible approach. I wonder if other AX back ends need to react to this notification too.

[Xan Lopez]

Thanks, I've landed this in r46574 with a small comment explaining why do we emit the notifications from the DOM tree.