[Webkit-unassigned] [Bug 54116] New: [GTK] Add support in DRT to log "accessibility events"

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=54116

           Summary: [GTK] Add support in DRT to log "accessibility events"
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: msanchez at igalia.com
                CC: xan.lopez at gmail.com, cfleizach at apple.com,
                    mrobinson at webkit.org


At the moment, there's no easy way to check, from a Layout Test, that some accessibility-related events happen when the user interacts with the content of an HTML file.

In the case of the GTK port, it would be very helpful if we could combine the usage of the eventSender, to simulate user interaction, with checking that the right (ATK specific) signals are emitted by WebKitGTK, which is something that can't be done right now. In this case (GTK), those signals would be the "accessibility events" mentioned in the title, but those could be something else for other platforms, or even extended to other stuff (not just signals) in the GTK port if needed.

As an example to showcase what I'm talking about, this could be the actual output (GTK specific) for a layout test using this new stuff:

   Accessibility object emitted "focus-event = 0" / Name: "baz" / Role: 34
   Accessibility object emitted "state-change:focused = 0" / Name: "baz" / Role: 34
   Accessibility object emitted "state-change:selected = 1" / Name: "bar" / Role: 34
   Accessibility object emitted "focus-event = 1" / Name: "bar" / Role: 34
   Accessibility object emitted "state-change:focused = 1" / Name: "bar" / Role: 34
   Accessibility object emitted "focus-event = 1" / Name: "foo" / Role: 11
   Accessibility object emitted "state-change:focused = 1" / Name: "foo" / Role: 11
   Accessibility object emitted "focus-event = 0" / Name: "bar" / Role: 34
   Accessibility object emitted "state-change:focused = 0" / Name: "bar" / Role: 34
   Accessibility object emitted "state-change:selected = 1" / Name: "foo" / Role: 34
   Accessibility object emitted "focus-event = 1" / Name: "foo" / Role: 34
   Accessibility object emitted "state-change:focused = 1" / Name: "foo" / Role: 34

   Bla bla bla.

   On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".


   PASS successfullyParsed is true

   TEST COMPLETE


Last but not least, this is very important addition for WebKitGTK since it blocks the proper implementation of tests (e.g. it would be needed to test the patch for bug 53146) involving the emission of signal, which is something we were working around by implementing unit tests instead of layout tests. But this is not always possible (as for bug 53146) so something like this would be really helpful indeed.

Chris, I adding you to CC because I guess you might be interested on this stuff. Feel free to ignore it otherwise :-)

Attaching a patch I've been working this afternoon in some minutes...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.