Bug 54116 - [GTK] Add support in DRT to log "accessibility events"
Summary: [GTK] Add support in DRT to log "accessibility events"
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 53146
  Show dependency treegraph
 
Reported: 2011-02-09 10:10 PST by Mario Sanchez Prada
Modified: 2011-02-10 01:03 PST (History)
3 users (show)

See Also:


Attachments
Patch proposal (11.68 KB, patch)
2011-02-09 11:00 PST, Mario Sanchez Prada
no flags Details | Formatted Diff | Diff
Patch proposal (12.17 KB, patch)
2011-02-09 13:59 PST, Mario Sanchez Prada
cfleizach: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Sanchez Prada 2011-02-09 10:10:45 PST
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...
Comment 1 Mario Sanchez Prada 2011-02-09 10:11:39 PST
Blocking bug 53146, as this stuff (or something similar) would be required to implement a proper test.
Comment 2 Mario Sanchez Prada 2011-02-09 11:00:38 PST
Created attachment 81837 [details]
Patch proposal

Attaching a patch proposal, with a specific implementation for GTK and dummy ones for Mac and Win.
Comment 3 Mario Sanchez Prada 2011-02-09 13:59:34 PST
Created attachment 81867 [details]
Patch proposal

Sorry, this is the right one to review
Comment 4 chris fleizach 2011-02-09 23:03:27 PST
Comment on attachment 81867 [details]
Patch proposal

View in context: https://bugs.webkit.org/attachment.cgi?id=81867&action=review

r=me

> Tools/DumpRenderTree/AccessibilityController.cpp:86
> +

Seems like this should take an argument (true/false) so you can turn this on or off
Comment 5 Mario Sanchez Prada 2011-02-10 00:49:59 PST
(In reply to comment #4)
> (From update of attachment 81867 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=81867&action=review
> 
> r=me
>

Thanks for the quick review!

> > Tools/DumpRenderTree/AccessibilityController.cpp:86
> > +
> 
> Seems like this should take an argument (true/false) so you can turn this on or off

I just followed the same pattern I've seen for other functions, such as logFocusEvents and logValueChangeEvents: you just enable the feature once per test (with accessibilityController.logAccessibilityEvents()) and it gets always reset in the AccessibilityController::resetToConsistentState() method.

I think that's enough for this cases, but if you (well, or somebody else) think it would be better to add that extra flexibility just file a bug, or ask me to do it so, and I gladly add that feature as well.
Comment 6 Mario Sanchez Prada 2011-02-10 01:03:55 PST
Committed r78179: <http://trac.webkit.org/changeset/78179>