[webkit-gtk] testing text-caret-moved events

Mario Sanchez Prada mario at webkit.org
Fri May 2 17:32:01 PDT 2014

Hi Jarek,

On Fri, 2014-05-02 at 09:43 +0200, Jarek Czekalski wrote:
> text-caret-moved is an event specific to gtk build, AFAIK. Seems like 
> other platforms have no similar event. So I chose this list to discuss 
> this issue.

text-caret-moved is an ATK signal, meaning that it's emitted both in the
GTK and EFL port, since the two of them use ATK to implement the
port-specific bits of the accessibility support.

> When webkit1 was active, tests for this event were carried out in 
> testatk.c. I tried to find a way to perform the same tests using 
> LayoutTests style, but failed. I assume it's not possible.

It's possible, but you need to need to extend first the functionality of
WebKitTestRunner's AccessibilityController and AccessibilityUIElement
classes for ATK, in order to enable the addNotificationListener()
JavaScript function to work with this ATK signal.

In other words, you need to connect to the "test-caret-moved" signal in
WKTR's AccessibilityNotificationListenerAtk.cpp, map it to something
like "AXTextCaretMoved" and then use that from the layout tests to
capture the events and check whether they are the right ones according
to the movement of the caret.

Also, remember to enable the caret mode for the tests with

You can see examples of how to use addNotificationListener() by grepping
in LayoutTests/, in [platform/gtk/]accessibility.

> If it's not possible, then definitely someone was thinking about the 
> ways it could be made possible. Please share your thoughts. I have some 
> ideas, but would prefer to give the voice first to guys with more 
> experience.

Check my paragraph above and let me know if that makes sense to you and
whether it helps you in any way to progress. But if it doesn't help you,
please do not hesitate to ask again :)

> By the way, I wonder how mac platform deals with screen readers, if it 
> does not use any kind of caret moved events. Or do they?

I'm not sure about the exact details of how the Mac platform works, but
my understanding is that they achieve something similar to WebKitGTK's
"caret browsing" by means of what they call the "VoiceOver cursor",
which lives outside WebKit, in the "VoiceOver" screen reader

So, that would mean that the Mac port of WebKit would not need to care
about caret browsing and/or these kind of events, since all that logic
would be handled outside of WebKit, inside VO.

Anyway, I might be completely wrong, so take all this with a grain of
salt. If you are really interested on knowing how this works, I'd
recommend you to take read more about how VoiceOver works and/or ask to
Chris Fleizach, from Apple. He's the man.

Have a nice weekend, and thanks again for your efforts!


More information about the webkit-gtk mailing list