Bug 53453

Summary: [Gtk] atk_text_get_selection/atk_text_set_selection fails for list items
Product: WebKit Reporter: Mario Sanchez Prada <mario>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, apinheiro, eric, jdiggs, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on:    
Bug Blocks: 25531    
Attachments:
Description Flags
Patch proposal + unit test mrobinson: review+

Mario Sanchez Prada
Reported 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)
Attachments
Patch proposal + unit test (12.15 KB, patch)
2011-02-07 15:02 PST, Mario Sanchez Prada 		mrobinson: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mario Sanchez Prada
Comment 1 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
Martin Robinson
Comment 2 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?
Mario Sanchez Prada
Comment 3 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.
Mario Sanchez Prada
Comment 4 2011-02-18 01:41:16 PST
Committed r78978: <http://trac.webkit.org/changeset/78978>
WebKit Review Bot
Comment 5 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
Note You need to log in before you can comment on or make changes to this bug.