Bug 130941 – [ATK] No accessible caret-moved events in a href display:block in div

• Component: Accessibility
• Status: RESOLVED FIXED

[Jarek Czekalski]

Created attachment 228124 [details]
html file to reproduce the bug

Gnome-help contains "a" tag with css style display:block as the only element inside a div. In such cases webkit does not emit "caret-moved" events. While chasing the bug I discovered also other cases were the event is not sent.

I attach an example html file with 8 lines. It shows all the possibilities of "a" tags considering 3 states:
1. with href attribute or not
2. with display:block style or not
3. as a single element inside a div or without a div
The 4 lines that exhibit the bug are marked with "-" at the beginning.

To reproduce the bug use means similar as those in bug #76069, bug #72811. I launch yelp with block.html and run the python script like the one from https://bugs.webkit.org/attachment.cgi?id=115151

I will slowly work on more internal info about the bug and on providing the test cases (testatk.c). For now I discovered from Source/WebCore/editing/atk/FrameSelectionAtk.cpp that:
Errors in lines 2 and 6 are rejected by objectFocusedAndCaretOffsetUnignored.
Errors in lines 5 and 7 are rejected by the condition in emitTextSelectionChange.

[Radar WebKit Bug Importer]

<rdar://problem/16467594>

[Jarek Czekalski]

Created attachment 229800 [details]
a test case

Actually the html file I attached earlier demonstrates a different bug, that I reported as bug #131933. So I submit a new test case for the bug here, which actually resembles the problem in gnome help. This is the clue of the bug:

<div>
<p>Para 1</p>
<a style="display:block;" href="anything">An a tag with href</a>
<p>Para 2</p>
</div>

To the bug #131933 I attached a testatk.c patch which detects both problems. This patch is hard to divide into 2 pieces.

Actually the testatk.c patch contains additional divs in the test case shown above, they should rather be removed.

[Jarek Czekalski]

The crucial part is this:

    // Don't ignore links if the offset is being requested for a link.
    if (!referenceObject->isLink() && firstUnignoredParent->isLink())
        firstUnignoredParent = firstUnignoredParent->parentObjectUnignored();

objectFocusedAndCaretOffsetUnignored in Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp, line 1333

Our accessibility tree branch is as follows:
web_document -> link -> text
text is the role for which objectFocusedAndCaretOffsetUnignored is executed. It is not the link, it's the link's child. So the condition above results in dropping the caret moved event.

Why does this happen? Traces lead to r53072, which is commented as follows:

        Adjust the caret offset and object with focus to reflect the
        unignored parent of the static text object which contains the
        caret. This is necessary because the static text objects are
        no longer being exposed to ATs.

That's seems to contradict the current actual situation, where something under the link, being text, is exposed to atk. How do we deal with this? Why do we need to ignore links at all? Maybe some answers are in bug #30883 (related with r53072), but I have not read it yet. Just reporting the results so far.

[Jarek Czekalski]

I was wrong. The atk text object, whose parent is the link, is not exposed. That is the link has 0 children.

I tried to check if renderer()->isRenderObject() to stop ignoring block links. This works for the provided test case. Unfortunately gnome documentation still does not work, so I have to prepare another test case and think of a patch then.

[Jarek Czekalski]

Created attachment 233237 [details]
fix caret in a block, v1.00

Hello again, Mario!

I'm attaching another short patch. Please consider whether the suggested solution is correct.

It would be cleaner to use renderer()->isBlock instead of !renderer()->isInline(), but only the latter syntax may be easily merged into stable branch.

After this patch yelp title page becomes accessible in webkit1. I'm planning to ask for stable branch merge for this patch, which should be applied after:
1. Bug #132527
2. the hot fix for the above patch (contained in the ticket)
3. Bug #132349
4. Bug #130941 (the one here)

These patches apply almost cleanly to the stable branch, a small adjustment is needed for the first one.

Thanks in advance for the review.

[Mario Sanchez Prada]

Comment on attachment 233237 [details]
fix caret in a block, v1.00

Thanks for the patch, it does look good to me.

[WebKit Commit Bot]

Comment on attachment 233237 [details]
fix caret in a block, v1.00

Clearing flags on attachment: 233237

Committed r170359: <http://trac.webkit.org/changeset/170359>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.