Bug 53389 - [Gtk] atk_text_set_caret_offset returns True even when it is unsuccessful
Summary: [Gtk] atk_text_set_caret_offset returns True even when it is unsuccessful
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P3 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 25531 53388
  Show dependency treegraph
 
Reported: 2011-01-29 17:40 PST by Joanmarie Diggs (irc: joanie)
Modified: 2011-01-31 09:58 PST (History)
2 users (show)

See Also:


Attachments
Patch proposal + unit tests (10.63 KB, patch)
2011-01-31 09:17 PST, Mario Sanchez Prada
mrobinson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs (irc: joanie) 2011-01-29 17:40:04 PST
+++ This bug was initially created as a clone of Bug #53388 +++

Created an attachment (id=80582)
test case

Steps to reproduce:

1. Open the attached test case in Epiphany.

2. Using Accerciser, attempt to set the caret position within the paragraph and within the first list item, by:

A. Selecting the corresponding object in Accerciser's tree of accessible objects

B. Typing 'acc.queryText().setCaretOffset(n)' - where 'n' is the desired offset.

Expected results: You'd be able to set the caret offset for both objects. **Non-cloned stuff: AND if you could not, False would be returned.**

Actual results: You can set the caret offset for only the paragraph; not the list item. **Non-cloned stuff: BUT True is always returned.**
Comment 1 Joanmarie Diggs (irc: joanie) 2011-01-29 17:45:22 PST
Mario, related aside and/or good test: Ignoring Orca and just using the native caret navigation in Epiphany, I cannot arrow to the list item's number. And that's OK. If there's someplace we cannot place the caret, so be it. BUT, if you return False in those cases, an AT like Orca can see that it's a list item and reattempt positioning the caret at the first part of the text which is *not* the list item. (Make sense?)
Comment 2 Mario Sanchez Prada 2011-01-31 07:19:05 PST
Blocking 53388, as we need to fix this bug first so set_caret_offset returns FALSE when trying to set the caret in the marker for a list item.
Comment 3 Mario Sanchez Prada 2011-01-31 09:17:24 PST
Created attachment 80646 [details]
Patch proposal + unit tests

Attaching a patch to fix this issue.

Notice that I included the needed code to consider list item markers (so we return FALSE in case you try to set the caret in the middle of them), as it's part of the solution for this bug, even if bug 53388 is not fixed yet and hence set_caret_offset will return FALSE always regardless of the offset being in the item's marker or in the item's text :-)

Asking for review now...
Comment 4 Martin Robinson 2011-01-31 09:36:57 PST
Comment on attachment 80646 [details]
Patch proposal + unit tests

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

> Source/WebCore/accessibility/gtk/AccessibilityObjectWrapperAtk.cpp:1714
> +    RenderObject* renderer = toAccessibilityRenderObject(coreObject)->renderer();
> +    if (renderer && renderer->isListItem()) {
> +        String markerText = toRenderListItem(renderer)->markerTextWithSuffix();
> +        int markerLength = g_utf8_strlen(markerText.utf8().data(), -1);
> +        if (offset < markerLength)
> +            return FALSE;
> +
> +        // We need to adjust the offset for list items.
> +        offset -= markerLength;
> +    }

Please mention this change in the ChangeLog as well.
Comment 5 Mario Sanchez Prada 2011-01-31 09:58:15 PST
Committed r77137: <http://trac.webkit.org/changeset/77137>