Title: [268182] trunk
- Revision
- 268182
- Author
- akeer...@apple.com
- Date
- 2020-10-08 08:10:06 -0700 (Thu, 08 Oct 2020)
Log Message
[iOS] Blurring a text input and focusing a date input changes the scrollable area
https://bugs.webkit.org/show_bug.cgi?id=217325
<rdar://problem/69979171>
Reviewed by Wenson Hsieh.
Source/WebKit:
iOS 14 changed the presentation style of date/time pickers on iPhones.
Previously, date/time pickers would show up in the keyboard view. Now,
pickers are shown in UIContextMenus.
When the change was made, shouldShowKeyboardForElement in WKContentViewInteraction
was not updated to reflect the new behavior, and continued to return
true for date/time inputs.
This inaccuracy led to WKContentView ignoring the UIKeyboardWillHideNotification
when blurring a text input and focusing a date input, since it assumed
the keyboard would stay presented. Consequently, the UIScrollView
adjustments made when presenting the keyboard for the text input are not
reverted when presenting the date picker, leading to a permanent change
in the scrollable area.
To fix, update shouldShowKeyboardForElement to return false for date/time
inputs. Note that the original patch which changed the behavior
correctly updated [WKContentView requiresAccessoryView] but did not
update shouldShowKeyboardForElement. To prevent a similar mistake from
happening again, the logic which determines which input types have a
keyboard view was moved into elementTypeRequiresAccessoryView.
Test: fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html
* UIProcess/ios/WKContentViewInteraction.mm:
(elementTypeRequiresAccessoryView):
(-[WKContentView requiresAccessoryView]):
(shouldShowKeyboardForElement):
LayoutTests:
Added a regression test which focuses a text input, then focuses a date
input, and finally attempts to scroll the content.
* fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields-expected.txt: Added.
* fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (268181 => 268182)
--- trunk/LayoutTests/ChangeLog 2020-10-08 13:45:50 UTC (rev 268181)
+++ trunk/LayoutTests/ChangeLog 2020-10-08 15:10:06 UTC (rev 268182)
@@ -1,3 +1,17 @@
+2020-10-08 Aditya Keerthi <akeer...@apple.com>
+
+ [iOS] Blurring a text input and focusing a date input changes the scrollable area
+ https://bugs.webkit.org/show_bug.cgi?id=217325
+ <rdar://problem/69979171>
+
+ Reviewed by Wenson Hsieh.
+
+ Added a regression test which focuses a text input, then focuses a date
+ input, and finally attempts to scroll the content.
+
+ * fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields-expected.txt: Added.
+ * fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html: Added.
+
2020-10-08 Per Arne Vollan <pvol...@apple.com>
[macOS] Deny access to performance analysis service in the WebContent process
Added: trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields-expected.txt (0 => 268182)
--- trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields-expected.txt 2020-10-08 15:10:06 UTC (rev 268182)
@@ -0,0 +1,10 @@
+This test verifies that focusing an element that presents a keyboard, and then focusing an element which dismisses the keyboard, does not change the scrollable area.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+PASS document.scrollingElement.scrollTop is 0
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html (0 => 268182)
--- trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html (rev 0)
+++ trunk/LayoutTests/fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html 2020-10-08 15:10:06 UTC (rev 268182)
@@ -0,0 +1,36 @@
+<!DOCTYPE html>
+<html>
+<head>
+ <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
+ <script src=""
+ <script src=""
+</head>
+<body>
+ <input id="text" type="text">
+ <input id="date" type="date" value="2020-10-07">
+ <script>
+ jsTestIsAsync = true;
+
+ textInput = document.getElementById("text");
+ dateInput = document.getElementById("date");
+
+ addEventListener("load", async () => {
+ description("This test verifies that focusing an element that presents a keyboard, and then focusing an element which dismisses the keyboard, does not change the scrollable area.");
+
+ await UIHelper.setHardwareKeyboardAttached(false);
+
+ await UIHelper.activateElementAndWaitForInputSession(text);
+ await UIHelper.activateElementAndWaitForInputSession(date);
+
+ document.activeElement.blur();
+ await UIHelper.waitForKeyboardToHide();
+
+ await UIHelper.dragFromPointToPoint(160, 150, 160, 50, 0.1);
+ await UIHelper.ensureStablePresentationUpdate();
+ shouldBeEqualToNumber("document.scrollingElement.scrollTop", 0);
+
+ finishJSTest();
+ });
+ </script>
+</body>
+</html>
Modified: trunk/Source/WebKit/ChangeLog (268181 => 268182)
--- trunk/Source/WebKit/ChangeLog 2020-10-08 13:45:50 UTC (rev 268181)
+++ trunk/Source/WebKit/ChangeLog 2020-10-08 15:10:06 UTC (rev 268182)
@@ -1,3 +1,40 @@
+2020-10-08 Aditya Keerthi <akeer...@apple.com>
+
+ [iOS] Blurring a text input and focusing a date input changes the scrollable area
+ https://bugs.webkit.org/show_bug.cgi?id=217325
+ <rdar://problem/69979171>
+
+ Reviewed by Wenson Hsieh.
+
+ iOS 14 changed the presentation style of date/time pickers on iPhones.
+ Previously, date/time pickers would show up in the keyboard view. Now,
+ pickers are shown in UIContextMenus.
+
+ When the change was made, shouldShowKeyboardForElement in WKContentViewInteraction
+ was not updated to reflect the new behavior, and continued to return
+ true for date/time inputs.
+
+ This inaccuracy led to WKContentView ignoring the UIKeyboardWillHideNotification
+ when blurring a text input and focusing a date input, since it assumed
+ the keyboard would stay presented. Consequently, the UIScrollView
+ adjustments made when presenting the keyboard for the text input are not
+ reverted when presenting the date picker, leading to a permanent change
+ in the scrollable area.
+
+ To fix, update shouldShowKeyboardForElement to return false for date/time
+ inputs. Note that the original patch which changed the behavior
+ correctly updated [WKContentView requiresAccessoryView] but did not
+ update shouldShowKeyboardForElement. To prevent a similar mistake from
+ happening again, the logic which determines which input types have a
+ keyboard view was moved into elementTypeRequiresAccessoryView.
+
+ Test: fast/forms/ios/constant-scroll-area-when-moving-focus-between-fields.html
+
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (elementTypeRequiresAccessoryView):
+ (-[WKContentView requiresAccessoryView]):
+ (shouldShowKeyboardForElement):
+
2020-10-08 Per Arne Vollan <pvol...@apple.com>
[macOS] Deny access to performance analysis service in the WebContent process
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (268181 => 268182)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2020-10-08 13:45:50 UTC (rev 268181)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2020-10-08 15:10:06 UTC (rev 268182)
@@ -2934,15 +2934,9 @@
#endif
}
-- (BOOL)requiresAccessoryView
+static bool elementTypeRequiresAccessoryView(WebKit::InputType type)
{
- if ([_formInputSession accessoryViewShouldNotShow])
- return NO;
-
- if ([_formInputSession customInputAccessoryView])
- return YES;
-
- switch (_focusedElementInformation.elementType) {
+ switch (type) {
case WebKit::InputType::None:
case WebKit::InputType::Drawing:
case WebKit::InputType::Date:
@@ -2949,7 +2943,7 @@
case WebKit::InputType::DateTimeLocal:
case WebKit::InputType::Month:
case WebKit::InputType::Time:
- return NO;
+ return false;
case WebKit::InputType::Text:
case WebKit::InputType::Password:
case WebKit::InputType::Search:
@@ -2969,6 +2963,17 @@
}
}
+- (BOOL)requiresAccessoryView
+{
+ if ([_formInputSession accessoryViewShouldNotShow])
+ return NO;
+
+ if ([_formInputSession customInputAccessoryView])
+ return YES;
+
+ return elementTypeRequiresAccessoryView(_focusedElementInformation.elementType);
+}
+
- (UITextInputAssistantItem *)inputAssistantItem
{
return [_webView inputAssistantItem];
@@ -5814,13 +5819,10 @@
if (information.inputMode == WebCore::InputMode::None)
return false;
- if (information.elementType == WebKit::InputType::Drawing)
- return false;
-
if (mayContainSelectableText(information.elementType))
return true;
- return !WebKit::currentUserInterfaceIdiomIsPadOrMac();
+ return elementTypeRequiresAccessoryView(information.elementType);
}
static WebCore::FloatRect rectToRevealWhenZoomingToFocusedElement(const WebKit::FocusedElementInformation& elementInfo, const WebKit::EditorState& editorState)
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
