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

Issue 881721 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 1
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Spatnav searches offscreen when an offscreen iframe displays activeElement

Reported by hu...@vewd.com, Sep 7

Issue description

Actual:
When an offscreen* iframe displays the activeElement, spatnav searches for focus candidates around activeElement, even though its iframe, and therefore also activeElement, is outside the visual viewport.

* = completely outside the visual viewport.

Expected:
Spatnav should always search in the visual viewport. When the activeElement is offscreen, search should start from one of the visual viewport's edges.

This happens because IsRectOffscreen() measures visibility in the node's local frame, not in the topmost frame's viewport. The topmost frame's viewport equals the user's visual viewport.

We need to make this test pass:

TEST_F(SpatialNavigationTest,
       StartFromDocEdgeWhenOffscreenIframeDisplaysFocus) {
  SetBodyInnerHTML(
      "<!DOCTYPE html>"
      "<style>"
      "  iframe {"
      "    margin-top: 1200px;"
      "    height: 100px;"
      "    width: 100px;"
      "  }"
      "</style>"
      "<iframe id='iframe'></iframe>");

  SetChildFrameHTML(
      "<!DOCTYPE html>"
      "<a id='link'>link</a>");

  ChildDocument().View()->UpdateAllLifecyclePhases();
  Element* link = ChildDocument().getElementById("link");

  EXPECT_TRUE(IsRectOffscreen(&ChildDocument()));
  EXPECT_TRUE(IsRectOffscreen(link));

  EXPECT_EQ(SearchOrigin(RootViewport(&GetFrame()), link, kWebFocusTypeUp),
            BottomOfVisualViewport());
  EXPECT_EQ(SearchOrigin(RootViewport(&GetFrame()), link, kWebFocusTypeDown),
            TopOfVisualViewport());
}
 
Cc: bokan@chromium.org f...@opera.com
What's the easiest way to check if a Node is [partially] visible in the users's visual viewport?
Element::VisibleBoundsInVisualViewport might be sufficient (or work as a starting point.)
Hi, I have another question. How to we know a focusable element is 'really' visible or not? For example, even though a focusable element has visible rect, it can be hidden by overlaying another element.
I think that we should not give focus to not 'really' visible element because then user can't know where focus is. So I'm finding proper way to knowing that. Anyone have idea about that?
When IntersectionObserver v2 is implement there will exist a (pessimistic) estimate of visibility - but in general it's difficult to provide a 100% accurate answer to that query. A (rect) hit-testing query (on which IOv2 is being built) might be the best approximation ATM.
Owner: hu...@vewd.com
Status: Started (was: Available)
Summary: Spatnav searches offscreen when an offscreen iframe displays activeElement (was: Spatnav searches off screen when an offscreen iframe displays activeElement)
Project Member

Comment 6 by bugdroid1@chromium.org, Sep 27

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

commit 2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c
Author: Hugo Holgersson <hugoh@vewd.com>
Date: Thu Sep 27 15:32:19 2018

Snav: Test visibility through the visual viewport

Scenario:
activeElement (focus) resides in an *offscreen* iframe's viewport.

Problem:
Spatnav only checked if activeElement was visible in its localmost
frame. Even if that frame wasn't visible to the user, activeElement
was used as the starting point in the search for focus candidates.

Solution:
Do not only ensure that activeElement is visible in its own frame:
Also ensure that activeElement is being visible through the root
frame. We do this by testing visibility through VisualViewport.

Note:
Element::VisibleBoundsInVisualViewport() returns an empty rect if
an element is clipped by an iframe but VBIVV does not return an empty
rect if the element is clipped by an overflow div. That's why we
first still check the node's LayoutObject's VisualRectInDocument().
Let's fix this problem in Issue 889840.

Bug:  881721 
Change-Id: I091d07a4f1f909e947fce11a335e3e6fe756ce18
Reviewed-on: https://chromium-review.googlesource.com/1243246
Commit-Queue: Hugo Holgersson <hugoh@vewd.com>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594730}
[modify] https://crrev.com/2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c/third_party/blink/renderer/core/dom/element.cc
[modify] https://crrev.com/2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c/third_party/blink/renderer/core/dom/element.h
[modify] https://crrev.com/2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c/third_party/blink/renderer/core/page/spatial_navigation.cc
[modify] https://crrev.com/2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c/third_party/blink/renderer/core/page/spatial_navigation.h
[modify] https://crrev.com/2d15f116e86b84ab7ef96d45ca5f4d0f522c3e3c/third_party/blink/renderer/core/page/spatial_navigation_test.cc

Status: Fixed (was: Started)

Sign in to add a comment