RESOLVED DUPLICATE of bug 17450 Bug 59737
Focus and caret position should be updated when same-page links are followed
https://bugs.webkit.org/show_bug.cgi?id=59737
Summary Focus and caret position should be updated when same-page links are followed
Joanmarie Diggs
Reported 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!
Attachments
Patch proposal + Layout test (8.14 KB, patch)
2011-05-04 07:31 PDT, Mario Sanchez Prada
no flags
Mario Sanchez Prada
Comment 1 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.
Mario Sanchez Prada
Comment 2 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.
Joanmarie Diggs
Comment 3 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?
Mario Sanchez Prada
Comment 4 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
Eric Seidel (no email)
Comment 5 2011-06-02 08:04:51 PDT
Seems like kinda an odd AX feature, but gtk should do whatever works for Gtk...
Martin Robinson
Comment 6 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.
Mario Sanchez Prada
Comment 7 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>
Mario Sanchez Prada
Comment 8 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...
Mario Sanchez Prada
Comment 9 2011-06-03 05:38:16 PDT
Comment on attachment 92239 [details] Patch proposal + Layout test Obsoleting bug and clearing flags
Mario Sanchez Prada
Comment 10 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 ***
Note You need to log in before you can comment on or make changes to this bug.