Bug 53453 - [Gtk] atk_text_get_selection/atk_text_set_selection fails for list items
Summary: [Gtk] atk_text_get_selection/atk_text_set_selection fails for list items
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 25531
  Show dependency treegraph
 
Reported: 2011-01-31 14:41 PST by Mario Sanchez Prada
Modified: 2011-02-18 02:38 PST (History)
5 users (show)

See Also:


Attachments
Patch proposal + unit test (12.15 KB, patch)
2011-02-07 15:02 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 Mario Sanchez Prada 2011-01-31 14:41:09 PST
Due to the same reason behind bug 53388 and bug 53436, the actual behaviour with  atk_text_get_selection and atk_text_set_selection when applied to list items is not the expected one, hence needs fixing.

Steps to reproduce:

1. Open the test case attached to bug 53388 (attachment 80582 [details]) in Epiphany.

2. Select all the text right after the 'First' word (' item'), in the first list item.

3. Using Accerciser, attempt to get and set the selection within that list item, and check that the actual results, by:

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

B1. Typing 'acc.queryText().setSelection(0, 0, 5)'

  Expected outcome: False (as you shouldn't be able to select inside the item's marker)
  Actual outcome: True

B2. Typing 'acc.queryText().setSelection(0, 3, 8)'

  Expected outcome: True (+ you'll see the 'First' substring selected)
  Actual outcome: True (but nothing is selected)

C. Manually select the 'First' substring and type 'acc.queryText().getSelection(0)'

  Expected outcome: (0, 5)
  Actual outcome: (3, 8)
Comment 1 Mario Sanchez Prada 2011-02-07 15:02:35 PST
Created attachment 81533 [details]
Patch proposal + unit test

Attaching patch proposal + an unit test updated to check this new stuff
Comment 2 Martin Robinson 2011-02-17 15:42:21 PST
Comment on attachment 81533 [details]
Patch proposal + unit test

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

> Source/WebCore/accessibility/gtk/AccessibilityObjectWrapperAtk.cpp:1117
> +    int end = endOffset;

Why not just continue to use endOffset?
Comment 3 Mario Sanchez Prada 2011-02-18 01:36:57 PST
(In reply to comment #2)
> (From update of attachment 81533 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=81533&action=review
> 
> > Source/WebCore/accessibility/gtk/AccessibilityObjectWrapperAtk.cpp:1117
> > +    int end = endOffset;
> 
> Why not just continue to use endOffset?

Because we need to use its value even after having set 'end', which can change its value along the function, thus differing from the original endoffset value.
Comment 4 Mario Sanchez Prada 2011-02-18 01:41:16 PST
Committed r78978: <http://trac.webkit.org/changeset/78978>
Comment 5 WebKit Review Bot 2011-02-18 02:38:27 PST
http://trac.webkit.org/changeset/78978 might have broken GTK Linux 32-bit Release
The following tests are not passing:
fast/events/popup-when-select-change.html
fast/forms/listbox-hit-test-zoomed.html
fast/forms/listbox-typeahead-greek.html
fast/forms/select-type-ahead-non-latin.html
fast/spatial-navigation/snav-single-select.html
inspector/debugger/debug-inlined-scripts.html
inspector/debugger/debugger-no-nested-pause.html
inspector/debugger/debugger-step-in.html
platform/gtk/accessibility/combo-box-collapsed-selection-changed.html
platform/gtk/fast/forms/menulist-typeahead-find.html