Bug 76069

Summary: [GTK] ATK text-caret-moved and text-selection-changed events not being emitted
Product: WebKit Reporter: Mario Sanchez Prada <mario>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: cfleizach, dglazkov, gns, gustavo.noronha, mrobinson, webkit.review.bot, xan.lopez
Priority: P2 Keywords: Gtk
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Linux   
Bug Depends on: 76267    
Bug Blocks: 25531    
Attachments:
Description Flags
Patch proposal
mrobinson: review+
Patch proposal
mrobinson: review-
Patch proposal
none
Patch proposal
webkit-ews: commit-queue-
Patch proposal mrobinson: review+

Description Mario Sanchez Prada 2012-01-11 09:32:56 PST
It seems that the fix for bug 72830 broke this as no 'text-caret-moved' event is being emitted when the caret moves across the text since it was applied.

To reproduce this bug, just do this:

1. Build WKGTK from trunk
2. Launch a browser (e.g. Epiphany) linked against that fresh WK build
3. Enable caret browsing by pressing F7
4. Position the caret anywhere in the test
5. Launch the following script: https://bugs.webkit.org/attachment.cgi?id=115151 (provided for bug 72382)

Expected: you should see text-caret-moved events showing up in the terminal

Actual: Nothing happens

This is a very important bug we should fix asap, and make sure we provide a proper unit test for it to avoid breaking things again in the future.
Comment 1 Mario Sanchez Prada 2012-01-12 03:15:32 PST
Updating the title to better reflect the issue (the caret is an special kind of selection)
Comment 2 Mario Sanchez Prada 2012-01-12 03:21:56 PST
Created attachment 122203 [details]
Patch proposal

The patch basically restores the original code in FrameSelectionGtk.cpp (not related actually to the fix for bug 72830) and adds more checks in testatk.c to ensure this never ever happen again (cross fingers!).
Comment 3 Mario Sanchez Prada 2012-01-12 03:29:00 PST
As the reviewer for path in Bug 72830, I think Martin might be interested in checking this one.
Comment 4 Mario Sanchez Prada 2012-01-13 01:12:59 PST
Committed r104905: <http://trac.webkit.org/changeset/104905>
Comment 5 Mario Sanchez Prada 2012-01-13 05:14:55 PST
It seems this is not properly fixed yet. The patch caused trouble in the GTK 64 bit Debug bot, so I had to roll it out: https://bugs.webkit.org/show_bug.cgi?id=76267
Comment 6 Mario Sanchez Prada 2012-01-16 07:52:18 PST
Created attachment 122637 [details]
Patch proposal

(In reply to comment #5)
> It seems this is not properly fixed yet. The patch caused trouble in the GTK 64 bit Debug bot, so I had to roll it out: https://bugs.webkit.org/show_bug.cgi?id=76267

The attached new patch uses positionBeforeNode instead of firstPositionInNode (which should be equivalent in this case, while not making that ASSERT fail) and also takes special care on the fact that the reference object passed to objectFocusedAndCaretOffsetUnignored should either be the same object being actually considered (and returned) or an ascendant, but never a descendant of such actual object.

I tested it in a debug 64bit build and seems to pass both the unit and layout tests. That must mean something
Comment 7 Martin Robinson 2012-01-16 08:43:56 PST
Comment on attachment 122637 [details]
Patch proposal

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

> Source/WebCore/accessibility/gtk/AccessibilityObjectWrapperAtk.cpp:2745
> +    AccessibilityObject* actualObject = focusedObject;

Is the goal here to find the first unignored object among the focused object and its parents? actualObject is a bad name, I think. Consider something like firstUnignoredParentOfFocusedObject.

> Source/WebCore/accessibility/gtk/AccessibilityObjectWrapperAtk.cpp:2761
> +    // Make sure the reference object gets now updated if the focused
> +    // object was pointing to it, so we don't have the reference
> +    // object as a descendant of the actual object being considered.
> +    if (focusedObject != referenceObject)
> +        referenceObject = actualObject;

This comment seems wrong: Should it say "Make sure the reference object is updated if the focused object was *different?" Can't you do this check more directly by just checking if referenceObject is a descendant of focusedObject or actualObject?

You say in your comment " so we don't have the reference object as a descendant of the actual object being considered," but this can still happen if focusedObject == referenceObject and focusedObject is ignored in the a11y tree.  I find this code, in general, pretty confusing.
Comment 8 Mario Sanchez Prada 2012-01-16 09:55:14 PST
Created attachment 122657 [details]
Patch proposal

New patch, trying to address the issues pointed out by Martin before.

This one introduces a couple of new -yet pretty simple- functions in AccessibilityObject: isDescendantOf() and contains() (in a similar way to those already present in Node).
Comment 9 Martin Robinson 2012-01-20 09:20:13 PST
Comment on attachment 122657 [details]
Patch proposal

This looks good to me. r=me if you can get Chris to look at the platform-independent changes.
Comment 10 Mario Sanchez Prada 2012-01-20 09:25:26 PST
Adding Chris to CC to check if he agrees with the cross-platform changes (the 2 new functions in AccessibilityObject)
Comment 11 chris fleizach 2012-01-20 11:14:18 PST
Comment on attachment 122657 [details]
Patch proposal

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

otherwise seems ok

> Source/WebCore/accessibility/AccessibilityObject.cpp:1297
> +bool AccessibilityObject::isDescendantOf(const AccessibilityObject* axObject) const

I would name this isDescendantOfObject

> Source/WebCore/accessibility/AccessibilityObject.cpp:1309
> +bool AccessibilityObject::contains(const AccessibilityObject* axObject) const

i would name this isAncestorOfObject
Comment 12 Mario Sanchez Prada 2012-01-21 06:33:12 PST
Created attachment 123447 [details]
Patch proposal

Attaching a new patch incorporating Chris's suggestions
Comment 13 Early Warning System Bot 2012-01-21 06:42:05 PST
Comment on attachment 123447 [details]
Patch proposal

Attachment 123447 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/11274049
Comment 14 Gyuyoung Kim 2012-01-21 06:42:52 PST
Comment on attachment 123447 [details]
Patch proposal

Attachment 123447 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11258069
Comment 15 WebKit Review Bot 2012-01-21 07:00:52 PST
Comment on attachment 123447 [details]
Patch proposal

Attachment 123447 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11119082
Comment 16 Collabora GTK+ EWS bot 2012-01-21 07:07:45 PST
Comment on attachment 123447 [details]
Patch proposal

Attachment 123447 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/11323012
Comment 17 Mario Sanchez Prada 2012-01-21 07:18:26 PST
Sorry, uploaded the wrong patch... will upload the right one soon
Comment 18 Mario Sanchez Prada 2012-01-21 07:50:43 PST
Created attachment 123448 [details]
Patch proposal

Now the right one. Sorry again.
Comment 19 Mario Sanchez Prada 2012-01-22 11:29:19 PST
Committed r105590: <http://trac.webkit.org/changeset/105590>