[webkit-gtk] Moving the caret with "enable-caret-browsing" set

Mario Sanchez Prada mario at webkit.org
Tue Nov 6 07:43:49 PST 2012

Hi Nicholas,

On Sat, 2012-11-03 at 20:06 -0400, Nicholas Bishop wrote:
> As suggested, I am trying out the Atk API to move the caret. I didn't
> see any public webkit_web_view_get_accessible() function, but
> gtk_widget_get_accessible() seems to do the trick.

Yes, sorry for the confusion. gtk_widget_get_accessible() is what you
have to use, not the other one :-)

> I'm trying to figure out how to use the API for this by printing out
> the AtkObject tree of a webkit view. What I cannot see is any property
> that indicates where in the tree the caret currently is. Calling
> atk_text_get_caret_offset() on an AtkText object in the tree gives
> mysterious values -- objects that are nowhere near the caret have
> greater-than-zero values. There doesn't seem to be a signal value like
> -1 to indicate the caret isn't there.

In theory when you call atk_text_get_caret_offset() over an
accessibility object implementing AtkText you'll get the offset relative
to the start of the text for that object.

For instance, if you have this HTML rendered:

    Some text with <a href="foo">a link</a> in the middle

You will have the following accessibility subtree:

  AtkObject1       // For <p>, implementing AtkText
    `--AtkObject2  // For <a>, implementing AtkText

The result of calling atk_text, get_text (object, 0, -1) over those two
objects would be:

 - For AtkObject1: "Some text with a link in the middle"
 - For AtkObject2: "a link"

Now, if the caret is right before the 'l' of 'link', calling
atk_text_get_caret_offset () over those two objects should give you
something like this:

 - For AtkObject1: 17
 - For AtkObject2: 2

Not sure if that answers your question, though.

> I also tried getting the AtkStateSet for text objects, but it only
> ATK_STATE_SHOWING, and ATK_STATE_VISIBLE. I was hoping the one with
> the caret would have ATK_STATE_FOCUSED, but seems not.

IIRC, objects representing non-editable text can't be "focused". That
would work for text entries and text areas.

> Finally, I tried atk_text_get_n_selections() to see if the caret
> counted as zero-length selection, but seems not.

Currently, atk_text_get_n_selections() is only implemented for range
selections. I think that's why it does not work.

> Any further hints?

It could be you spotted a bug. Would you mind sharing the exact HTML and
steps you're using to check this?

That way I could try to check it myself and hopefully help to advance on
this in a better way.


More information about the webkit-gtk mailing list