New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 891149 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 26 days ago
Closed: Oct 4
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Snav gives focus to undesirable element when current focused element is scrollable element.

Project Member Reported by junho092...@lge.com, Oct 2

Issue description

What steps will reproduce the problem?
(1) Launch chrome with --enable-spatial-navigation
(2) Open attached file
(3) give focus to overflow div element
(4) Hit up arrow key

What is the expected result?
Focus is moved to top most element("end").

What happens instead?
Focus is moved to left element("1")


 
snav-search-outside-of-focused-scroller.html
715 bytes View Download
Also we need test case for focused iframe element.
Project Member

Comment 2 by bugdroid1@chromium.org, Oct 4

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4835e88efcb0d89732a26732b09729c496917efd

commit 4835e88efcb0d89732a26732b09729c496917efd
Author: JunHo Seo <junho0924.seo@lge.com>
Date: Thu Oct 04 04:54:56 2018

Snav: Use bounding box for focused(and scrollable) element's search origin

Problem:
Let a focused(and scrollable) element's (visible) bounding box
is (x, y, w, h). If we hit down arrow key, then its result of
SearchOrigin() will be (x, y, w, 0), i.e. top edge of the element.
This introduces additional candidates are considered if we use the
result. Previously, we are considering an element that its bounding
rect is (x', y', w', h'), where y' >= y+h (except intersecting
candidate). But, if we use the result, an element (x'', y'', w'', h'')
where y <= y'' < y+h can be candidate.

Here is an example:
(x, y, w, h)
---------  (x'', y'', w'', h'')
|       |  -----
|   A   |  | C |
|       |  -----
---------

  (x', y', w', h)
  -----
  | B |
  -----

In above example, assume that we hit down arrow key. And element 'A'
is focused and scrollable element. If we use A's bounding box as
search origin, then only element 'B' is candidate for getting focus,
because y+h < y', y+h > y''. But if we use top edge of element
'A'(x, y, w, 0), element 'C' also can be candidate because y+0 < y''.
In point of intuitive, element 'C' is not in down side direction of
element 'A', so it should not be candidate in this scenario.

Solution:
Use bounding box for focused(and scrollable) element as well.
This CL also change SearchOrigin() from recursion to iteration.

Bug:  891149 
Change-Id: Ib9e3ba07859e6bfc415cd19f93b42cc33fda7c74
Reviewed-on: https://chromium-review.googlesource.com/c/1253523
Commit-Queue: JunHo Seo <junho0924.seo@lge.com>
Reviewed-by: Hugo Holgersson <hugoh@vewd.com>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#596508}
[add] https://crrev.com/4835e88efcb0d89732a26732b09729c496917efd/third_party/WebKit/LayoutTests/fast/spatial-navigation/snav-search-outside-of-focused-scroller.html
[modify] https://crrev.com/4835e88efcb0d89732a26732b09729c496917efd/third_party/blink/renderer/core/page/spatial_navigation.cc
[modify] https://crrev.com/4835e88efcb0d89732a26732b09729c496917efd/third_party/blink/renderer/core/page/spatial_navigation_test.cc

Status: Fixed (was: Started)

Sign in to add a comment