Bug 45177 – [Gtk] atk_text_set_caret_offset fails

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Accessibility

[Joanmarie Diggs]

Created attachment 66500 [details]
test case

Steps to reproduce:

1. Load the attached test case and enable caret browsing.

2. Select either the heading or paragraph in Accerciser's object tree.

3. With that object selected, and using Accerciser's iPython Console, type:

     acc.queryText().setCaretOffset(0)

4. Alt+Tab back into the browser (i.e. so as not to move the caret accidentally by clicking).

Expected results: The caret would be repositioned at the beginning of the object.

Actual results: The caret is not moved.

I suspect this is a causality of The Great Hierarchy Flattening and hoping Mario has time to take a look. (And add it towards the top of the stack. I'm working on Orca's Epiphany script, and really, really need to be able to set the caret.)

Thanks in advance!

[Mario Sanchez Prada]

I'm trying to reproduce this bug with latest code from WebKitGTK + Ephiphany (right from the git repos) and all I get is acc.queryText().setCaretOffset() working as expected.

I think it could possible this was an issue still present in the stable releases of ephy/webkit but already fixed in development branches. Joanmarie, if you could test this in your machine at some point to confirm I'm not missing something / doing something wrong, that would be great.

[Joanmarie Diggs]

(In reply to comment #1)

> I think it could possible this was an issue still present in
> the stable releases of ephy/webkit but already fixed in
> development branches

<embarrassed>

Yup, that was it. I'm so sorry. Ubuntu unstable has historically kept quite current with releases and thus I made a bogus assumption.

Having just built WebKitGtk, I can confirm that atk_text_set_caret_offset succeeds. Closing as WORKSFORME since JOANIEISANIDIOT is not an option. ;-)