Bug 59737 – Focus and caret position should be updated when same-page links are followed

• Component: Accessibility
• Status: RESOLVED DUPLICATE

[Joanmarie Diggs]

Steps to reproduce:

1. Launch Epiphany and enable caret browsing by pressing F7

2. Navigate to the wikipedia page of your choice, e.g. http://en.wikipedia.org/wiki/Zombies

3. Move focus to a link under the 'Contents' heading (e.g. 'Zombie apocalypse') and press Return. At this point the window scrolls to display the chosen heading.

4. Press Down Arrow to move to the next line within the chosen section's contents.

Expected results: The caret position would be updated to the next line of content under the chosen heading (e.g. 'Main article: Zombie apocalypse'). In addition, the appropriate accessible signals (focus:, object:state-changed:focused, and object:text-caret-moved) would be emitted.

Actual results: The caret and focus are each moved to the next link in the contents (e.g. 'Philosophical Zombie'). 

Note: I'm guessing that this is not technically the 'Accessibility' component, but I'm not sure which component it is. It is, however, a significant accessibility issue for users who are blind. CCing Mario for triage.

Thanks!

[Mario Sanchez Prada]

Looks like we could make the most of the GTK-specific method we have in AXObjectCacheAtk.cpp, called handleScrolledToAnchor(), which seems to fit pretty well in this case.

I'll try to come up with a patch for this soon.

[Mario Sanchez Prada]

Created attachment 92239 [details]
Patch proposal + Layout test

Patch proposal + layout test.

The implemented behaviour is specific to the GTK port.

[Joanmarie Diggs]

Thanks Mario! I'll build and test it soon. In the meantime, bug 17450 was just pointed out to me. It sounds quite similar to what I reported here. (I really did search and browse prior to filing. Honest! :-) ) Anyhoo, if this is a cross-platform issue, is a single cross-platform solution possible?

[Mario Sanchez Prada]

(In reply to comment #3)
> Thanks Mario! I'll build and test it soon. In the meantime, bug 17450 was just pointed out to me. It sounds quite similar to what I reported here. (I really did search and browse prior to filing. Honest! :-) ) Anyhoo, if this is a cross-platform issue, is a single cross-platform solution possible?

Sure! I just used that platform-specific method because it was exactly what I wanted to do for WebKitGTK, but I don't see much trouble in moving it to the general AXObjectCache code.

I'll comment on bug 17450

[Eric Seidel (no email)]

Seems like kinda an odd AX feature, but gtk should do whatever works for Gtk...

[Martin Robinson]

Comment on attachment 92239 [details]
Patch proposal + Layout test

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

Okay! Seems sane.

> Source/WebCore/accessibility/gtk/AXObjectCacheAtk.cpp:228
> +    Position targetPosition = firstPositionInOrBeforeNode(const_cast<Node*>(node));
> +    selection->moveTo(targetPosition, DOWNSTREAM);

This seems simple enough to make into one line. Please change before landing.

[Mario Sanchez Prada]

(In reply to comment #6)
> (From update of attachment 92239 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=92239&action=review
> 
> Okay! Seems sane.
> 
> > Source/WebCore/accessibility/gtk/AXObjectCacheAtk.cpp:228
> > +    Position targetPosition = firstPositionInOrBeforeNode(const_cast<Node*>(node));
> > +    selection->moveTo(targetPosition, DOWNSTREAM);
> 
> This seems simple enough to make into one line. Please change before landing.

Done.

Committed r88004: <http://trac.webkit.org/changeset/88004>

[Mario Sanchez Prada]

This patch caused some patches to start failing, so I've rolled it out: https://bugs.webkit.org/show_bug.cgi?id=62008

Btw, those patches only fail if running the accessibility layout tests before:

run-webkit-tests --gtk --debug accessibility fast/block/float/float-in-float-hit-testing.html fast/css/target-fragment-match.html t/dynamic/anchor-lock.html fast/overflow/overflow_hidden.html svg/custom/scrolling-embedded-svg-file-image-repaint-problem.html

...so it could be some interdependency issue among tests, triggered perhaps by the layout test in this bug.

Hence, reopening...

[Mario Sanchez Prada]

Comment on attachment 92239 [details]
Patch proposal + Layout test

Obsoleting bug and clearing flags

[Mario Sanchez Prada]

This bug has been fixed in a more general way with the patch for bug 17450

*** This bug has been marked as a duplicate of bug 17450 ***