Bug 59737 - Focus and caret position should be updated when same-page links are followed
Summary: Focus and caret position should be updated when same-page links are followed
Status: RESOLVED DUPLICATE of bug 17450
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL: http://wikipedia.org
Keywords:
Depends on: 62008
Blocks: 25531 17450
  Show dependency treegraph
 
Reported: 2011-04-28 14:17 PDT by Joanmarie Diggs (irc: joanie)
Modified: 2013-07-26 05:38 PDT (History)
5 users (show)

See Also:


Attachments
Patch proposal + Layout test (8.14 KB, patch)
2011-05-04 07:31 PDT, Mario Sanchez Prada
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs (irc: joanie) 2011-04-28 14:17:27 PDT
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!
Comment 1 Mario Sanchez Prada 2011-05-04 04:37:44 PDT
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.
Comment 2 Mario Sanchez Prada 2011-05-04 07:31:27 PDT
Created attachment 92239 [details]
Patch proposal + Layout test

Patch proposal + layout test.

The implemented behaviour is specific to the GTK port.
Comment 3 Joanmarie Diggs (irc: joanie) 2011-05-17 08:09:57 PDT
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?
Comment 4 Mario Sanchez Prada 2011-05-17 13:41:37 PDT
(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
Comment 5 Eric Seidel (no email) 2011-06-02 08:04:51 PDT
Seems like kinda an odd AX feature, but gtk should do whatever works for Gtk...
Comment 6 Martin Robinson 2011-06-02 08:36:08 PDT
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.
Comment 7 Mario Sanchez Prada 2011-06-03 04:12:03 PDT
(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>
Comment 8 Mario Sanchez Prada 2011-06-03 05:37:49 PDT
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...
Comment 9 Mario Sanchez Prada 2011-06-03 05:38:16 PDT
Comment on attachment 92239 [details]
Patch proposal + Layout test

Obsoleting bug and clearing flags
Comment 10 Mario Sanchez Prada 2013-07-26 05:38:59 PDT
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 ***