- Revision
- 272261
- Author
- [email protected]
- Date
- 2021-02-02 17:40:10 -0800 (Tue, 02 Feb 2021)
Log Message
Cherry-pick r271861. rdar://problem/73890854
[iOS] Obscured elements should not be focusable using the accessory bar
https://bugs.webkit.org/show_bug.cgi?id=220929
<rdar://problem/73239409>
Reviewed by Tim Horton.
Source/WebCore:
* rendering/HitTestResult.h:
Export function so it can be called from WebKit layer.
Source/WebKit:
Currently, assistable elements hidden behind unassistable elements can
be focused using the next/previous buttons on the accessory bar. This
behavior is undesirable since users cannot see the focused element, but
are still presented UI to enter information into the element.
While the current behavior has been longstanding, its undesirability was
exposed after r269059, which made it possible to use the accessory bar
to focus elements across focusable scopes. As a result, it became possible
to focus a hidden input field on appleid.apple.com using the accessory bar.
Note that the hidden field is inside a subframe, which was previously
excluded from accessory bar next/previous operations. However, the same
bug would still exist even if the field was not inside a subframe, which
means that r269059 is not the root cause of the issue, but simply exposed
a larger underlying problem.
To prevent obscured elements from being focusable using the accessory bar,
we now use hit testing to determine whether or not an element is obscured,
before considering the element "assistable".
Test: fast/forms/ios/accessory-bar-navigation-obscured-input.html
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::isObscuredElement):
An element is considered obscured if a hit test at its center position
relative to the main document targets a different element.
(WebKit::nextAssistableElement):
Obscured elements should not be assistable.
LayoutTests:
* fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt: Added.
* fast/forms/ios/accessory-bar-navigation-obscured-input.html: Added.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271861 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Added Paths
Diff
Modified: branches/safari-611-branch/LayoutTests/ChangeLog (272260 => 272261)
--- branches/safari-611-branch/LayoutTests/ChangeLog 2021-02-03 01:40:05 UTC (rev 272260)
+++ branches/safari-611-branch/LayoutTests/ChangeLog 2021-02-03 01:40:10 UTC (rev 272261)
@@ -1,5 +1,70 @@
2021-02-02 Alan Coon <[email protected]>
+ Cherry-pick r271861. rdar://problem/73890854
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ Source/WebCore:
+ * rendering/HitTestResult.h:
+
+ Export function so it can be called from WebKit layer.
+
+ Source/WebKit:
+ Currently, assistable elements hidden behind unassistable elements can
+ be focused using the next/previous buttons on the accessory bar. This
+ behavior is undesirable since users cannot see the focused element, but
+ are still presented UI to enter information into the element.
+
+ While the current behavior has been longstanding, its undesirability was
+ exposed after r269059, which made it possible to use the accessory bar
+ to focus elements across focusable scopes. As a result, it became possible
+ to focus a hidden input field on appleid.apple.com using the accessory bar.
+ Note that the hidden field is inside a subframe, which was previously
+ excluded from accessory bar next/previous operations. However, the same
+ bug would still exist even if the field was not inside a subframe, which
+ means that r269059 is not the root cause of the issue, but simply exposed
+ a larger underlying problem.
+
+ To prevent obscured elements from being focusable using the accessory bar,
+ we now use hit testing to determine whether or not an element is obscured,
+ before considering the element "assistable".
+
+ Test: fast/forms/ios/accessory-bar-navigation-obscured-input.html
+
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::isObscuredElement):
+
+ An element is considered obscured if a hit test at its center position
+ relative to the main document targets a different element.
+
+ (WebKit::nextAssistableElement):
+
+ Obscured elements should not be assistable.
+
+ LayoutTests:
+ * fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt: Added.
+ * fast/forms/ios/accessory-bar-navigation-obscured-input.html: Added.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271861 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2021-01-25 Aditya Keerthi <[email protected]>
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ * fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt: Added.
+ * fast/forms/ios/accessory-bar-navigation-obscured-input.html: Added.
+
+2021-02-02 Alan Coon <[email protected]>
+
Cherry-pick r271786. rdar://problem/73890368
[iOS WK2] theverge.com - rubber band scrolling at the top of the page causes an abrupt jump
Added: branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt (0 => 272261)
--- branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt (rev 0)
+++ branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt 2021-02-03 01:40:10 UTC (rev 272261)
@@ -0,0 +1,18 @@
+Tests that obscured inputs are not focusable using the accessory bar.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+Focus the unobscured input.
+PASS document.activeElement is input
+
+Attempting to to use the accessory bar to focus an obscured input should preserve the existing focus.
+PASS document.activeElement is input
+
+Attempting to to use the accessory bar to focus an unobscured input should change focus.
+PASS document.activeElement is iframe
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
+
Added: branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input.html (0 => 272261)
--- branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input.html (rev 0)
+++ branches/safari-611-branch/LayoutTests/fast/forms/ios/accessory-bar-navigation-obscured-input.html 2021-02-03 01:40:10 UTC (rev 272261)
@@ -0,0 +1,46 @@
+<!DOCTYPE html> <!-- webkit-test-runner [ useFlexibleViewport=true ] -->
+<html>
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<head>
+<script src=""
+<script src=""
+<style>
+ #overlay {
+ background-color: red;
+ position: absolute;
+ width: 500px;
+ height: 500px;
+ }
+</style>
+</head>
+<body>
+<input id="input">
+<br>
+<div id="overlay"></div>
+<iframe id="iframe" srcdoc="<input>"></iframe>
+<script>
+jsTestIsAsync = true;
+
+description("Tests that obscured inputs are not focusable using the accessory bar.");
+addEventListener("load", async () => {
+ if (!window.testRunner)
+ return;
+
+ debug("Focus the unobscured input.");
+ await UIHelper.activateElement(input);
+ shouldBe("document.activeElement", "input");
+
+ debug("\nAttempting to to use the accessory bar to focus an obscured input should preserve the existing focus.");
+ await UIHelper.moveToNextByKeyboardAccessoryBar();
+ shouldBe("document.activeElement", "input");
+
+ debug("\nAttempting to to use the accessory bar to focus an unobscured input should change focus.");
+ overlay.style.display = "none";
+ await UIHelper.moveToNextByKeyboardAccessoryBar();
+ shouldBe("document.activeElement", "iframe");
+
+ finishJSTest();
+});
+</script>
+</body>
+</html>
Modified: branches/safari-611-branch/Source/WebCore/ChangeLog (272260 => 272261)
--- branches/safari-611-branch/Source/WebCore/ChangeLog 2021-02-03 01:40:05 UTC (rev 272260)
+++ branches/safari-611-branch/Source/WebCore/ChangeLog 2021-02-03 01:40:10 UTC (rev 272261)
@@ -1,5 +1,71 @@
2021-02-02 Alan Coon <[email protected]>
+ Cherry-pick r271861. rdar://problem/73890854
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ Source/WebCore:
+ * rendering/HitTestResult.h:
+
+ Export function so it can be called from WebKit layer.
+
+ Source/WebKit:
+ Currently, assistable elements hidden behind unassistable elements can
+ be focused using the next/previous buttons on the accessory bar. This
+ behavior is undesirable since users cannot see the focused element, but
+ are still presented UI to enter information into the element.
+
+ While the current behavior has been longstanding, its undesirability was
+ exposed after r269059, which made it possible to use the accessory bar
+ to focus elements across focusable scopes. As a result, it became possible
+ to focus a hidden input field on appleid.apple.com using the accessory bar.
+ Note that the hidden field is inside a subframe, which was previously
+ excluded from accessory bar next/previous operations. However, the same
+ bug would still exist even if the field was not inside a subframe, which
+ means that r269059 is not the root cause of the issue, but simply exposed
+ a larger underlying problem.
+
+ To prevent obscured elements from being focusable using the accessory bar,
+ we now use hit testing to determine whether or not an element is obscured,
+ before considering the element "assistable".
+
+ Test: fast/forms/ios/accessory-bar-navigation-obscured-input.html
+
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::isObscuredElement):
+
+ An element is considered obscured if a hit test at its center position
+ relative to the main document targets a different element.
+
+ (WebKit::nextAssistableElement):
+
+ Obscured elements should not be assistable.
+
+ LayoutTests:
+ * fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt: Added.
+ * fast/forms/ios/accessory-bar-navigation-obscured-input.html: Added.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271861 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2021-01-25 Aditya Keerthi <[email protected]>
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ * rendering/HitTestResult.h:
+
+ Export function so it can be called from WebKit layer.
+
+2021-02-02 Alan Coon <[email protected]>
+
Cherry-pick r271786. rdar://problem/73890368
[iOS WK2] theverge.com - rubber band scrolling at the top of the page causes an abrupt jump
Modified: branches/safari-611-branch/Source/WebCore/rendering/HitTestResult.h (272260 => 272261)
--- branches/safari-611-branch/Source/WebCore/rendering/HitTestResult.h 2021-02-03 01:40:05 UTC (rev 272260)
+++ branches/safari-611-branch/Source/WebCore/rendering/HitTestResult.h 2021-02-03 01:40:10 UTC (rev 272261)
@@ -89,7 +89,7 @@
const LayoutPoint& localPoint() const { return m_localPoint; }
void setLocalPoint(const LayoutPoint& p) { m_localPoint = p; }
- void setToNonUserAgentShadowAncestor();
+ WEBCORE_EXPORT void setToNonUserAgentShadowAncestor();
const HitTestLocation& hitTestLocation() const { return m_hitTestLocation; }
Modified: branches/safari-611-branch/Source/WebKit/ChangeLog (272260 => 272261)
--- branches/safari-611-branch/Source/WebKit/ChangeLog 2021-02-03 01:40:05 UTC (rev 272260)
+++ branches/safari-611-branch/Source/WebKit/ChangeLog 2021-02-03 01:40:10 UTC (rev 272261)
@@ -1,5 +1,98 @@
2021-02-02 Alan Coon <[email protected]>
+ Cherry-pick r271861. rdar://problem/73890854
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ Source/WebCore:
+ * rendering/HitTestResult.h:
+
+ Export function so it can be called from WebKit layer.
+
+ Source/WebKit:
+ Currently, assistable elements hidden behind unassistable elements can
+ be focused using the next/previous buttons on the accessory bar. This
+ behavior is undesirable since users cannot see the focused element, but
+ are still presented UI to enter information into the element.
+
+ While the current behavior has been longstanding, its undesirability was
+ exposed after r269059, which made it possible to use the accessory bar
+ to focus elements across focusable scopes. As a result, it became possible
+ to focus a hidden input field on appleid.apple.com using the accessory bar.
+ Note that the hidden field is inside a subframe, which was previously
+ excluded from accessory bar next/previous operations. However, the same
+ bug would still exist even if the field was not inside a subframe, which
+ means that r269059 is not the root cause of the issue, but simply exposed
+ a larger underlying problem.
+
+ To prevent obscured elements from being focusable using the accessory bar,
+ we now use hit testing to determine whether or not an element is obscured,
+ before considering the element "assistable".
+
+ Test: fast/forms/ios/accessory-bar-navigation-obscured-input.html
+
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::isObscuredElement):
+
+ An element is considered obscured if a hit test at its center position
+ relative to the main document targets a different element.
+
+ (WebKit::nextAssistableElement):
+
+ Obscured elements should not be assistable.
+
+ LayoutTests:
+ * fast/forms/ios/accessory-bar-navigation-obscured-input-expected.txt: Added.
+ * fast/forms/ios/accessory-bar-navigation-obscured-input.html: Added.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271861 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2021-01-25 Aditya Keerthi <[email protected]>
+
+ [iOS] Obscured elements should not be focusable using the accessory bar
+ https://bugs.webkit.org/show_bug.cgi?id=220929
+ <rdar://problem/73239409>
+
+ Reviewed by Tim Horton.
+
+ Currently, assistable elements hidden behind unassistable elements can
+ be focused using the next/previous buttons on the accessory bar. This
+ behavior is undesirable since users cannot see the focused element, but
+ are still presented UI to enter information into the element.
+
+ While the current behavior has been longstanding, its undesirability was
+ exposed after r269059, which made it possible to use the accessory bar
+ to focus elements across focusable scopes. As a result, it became possible
+ to focus a hidden input field on appleid.apple.com using the accessory bar.
+ Note that the hidden field is inside a subframe, which was previously
+ excluded from accessory bar next/previous operations. However, the same
+ bug would still exist even if the field was not inside a subframe, which
+ means that r269059 is not the root cause of the issue, but simply exposed
+ a larger underlying problem.
+
+ To prevent obscured elements from being focusable using the accessory bar,
+ we now use hit testing to determine whether or not an element is obscured,
+ before considering the element "assistable".
+
+ Test: fast/forms/ios/accessory-bar-navigation-obscured-input.html
+
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::isObscuredElement):
+
+ An element is considered obscured if a hit test at its center position
+ relative to the main document targets a different element.
+
+ (WebKit::nextAssistableElement):
+
+ Obscured elements should not be assistable.
+
+2021-02-02 Alan Coon <[email protected]>
+
Cherry-pick r271786. rdar://problem/73890368
[iOS WK2] theverge.com - rubber band scrolling at the top of the page causes an abrupt jump
Modified: branches/safari-611-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (272260 => 272261)
--- branches/safari-611-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2021-02-03 01:40:05 UTC (rev 272260)
+++ branches/safari-611-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2021-02-03 01:40:10 UTC (rev 272261)
@@ -2553,6 +2553,23 @@
return element.isContentEditable();
}
+static inline bool isObscuredElement(Element& element)
+{
+ auto topDocument = makeRef(element.document().topDocument());
+ auto elementRectInMainFrame = element.clientRect();
+
+ constexpr OptionSet<HitTestRequest::RequestType> hitType { HitTestRequest::ReadOnly, HitTestRequest::Active, HitTestRequest::AllowChildFrameContent, HitTestRequest::DisallowUserAgentShadowContent };
+ HitTestResult result(elementRectInMainFrame.center());
+
+ topDocument->hitTest(hitType, result);
+ result.setToNonUserAgentShadowAncestor();
+
+ if (result.targetElement() == &element)
+ return false;
+
+ return true;
+}
+
void WebPage::getPositionInformation(const InteractionInformationRequest& request, CompletionHandler<void(InteractionInformationAtPosition&&)>&& reply)
{
// Avoid UIProcess hangs when the WebContent process is stuck on a sync IPC.
@@ -3029,7 +3046,7 @@
nextElement = isForward
? page.focusController().nextFocusableElement(*nextElement)
: page.focusController().previousFocusableElement(*nextElement);
- } while (nextElement && !isAssistableElement(*nextElement));
+ } while (nextElement && (!isAssistableElement(*nextElement) || isObscuredElement(*nextElement)));
return nextElement;
}
