Title: [243044] trunk
- Revision
- 243044
- Author
- [email protected]
- Date
- 2019-03-16 14:17:40 -0700 (Sat, 16 Mar 2019)
Log Message
[iOS] Software keyboard never appears when editing on some websites
https://bugs.webkit.org/show_bug.cgi?id=195824
<rdar://problem/48020610>
Reviewed by Ryosuke Niwa.
Source/WebKit:
In the scenario where an element has already been programmatically focused but the UI process isn't showing an
input view for it, there are a couple of different ways in which an input view may still be shown for that
element:
1. If the page attempts to programmatically focus the element, we'll invoke elementDidRefocus to recompute
information about the focused element and propagate it to the UI process. By default, if programmatic focus was
triggered under the scope of user interaction, we'll allow the input view to appear.
2. In the case where page does not attempt to programmatically focus the element but a click is dispatched,
there is logic in WebPage::completeSyntheticClick to send information about the already-focused element.
On the web page relevant to this bug, focus is programmatically moved to hidden contenteditable areas upon page
load, and touchstart is also prevented; furthermore, the page does not attempt to programmatically refocus the
hidden editable area upon receiving touchstart. This means that the user will never be able to bring up the
keyboard, since the editable area is already programmatically focused and subsequent attempts to tap in the
page do nothing, because the page has already focused the hidden editable area (with the expectation that the
software keyboard should already be present).
To fix this, we bring some of the same logic in completeSyntheticClick over to dispatchTouchEvent, by sending
focused element information to the UI process if the focused element did not change over the course of
dispatching the touch event. Similar code was introduced in r167774 to fix the same type of issue (i.e.
inability to bring up the software keyboard), but this was later reverted in r188405 due to causing bugs such as
<rdar://problem/22204108>, wherein this logic to bring up the keyboard in dispatchTouchEvent would scroll and
zoom the page, such that the click event fired after touchend would be dispatched in the wrong location and (in
the case of <rdar://problem/22204108>) caused the focused element to immediately blur again.
To mitigate this issue, we add the additional constraint that we only send focused element info in the case
where the touch won't also generate a click later down the road, by requiring that the dispatched event was
handled by the page (i.e. prevented).
Test: fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::dispatchTouchEvent):
LayoutTests:
Add a layout test to verify that tapping a programmatically focused textarea that prevents touchstart still
causes the keyboard to appear.
* fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt: Added.
* fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (243043 => 243044)
--- trunk/LayoutTests/ChangeLog 2019-03-16 19:54:18 UTC (rev 243043)
+++ trunk/LayoutTests/ChangeLog 2019-03-16 21:17:40 UTC (rev 243044)
@@ -1,3 +1,17 @@
+2019-03-16 Wenson Hsieh <[email protected]>
+
+ [iOS] Software keyboard never appears when editing on some websites
+ https://bugs.webkit.org/show_bug.cgi?id=195824
+ <rdar://problem/48020610>
+
+ Reviewed by Ryosuke Niwa.
+
+ Add a layout test to verify that tapping a programmatically focused textarea that prevents touchstart still
+ causes the keyboard to appear.
+
+ * fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt: Added.
+ * fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html: Added.
+
2019-03-16 Zalan Bujtas <[email protected]>
[iOS] Unable to close trending window on naver.com.
Added: trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt (0 => 243044)
--- trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart-expected.txt 2019-03-16 21:17:40 UTC (rev 243044)
@@ -0,0 +1,11 @@
+
+Verifies that the keyboard shows up even after preventing default on touchstart. To manually test, tap the textarea; the textarea should remain focused, and the keyboard should appear.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+PASS keyboard was shown.
+PASS document.activeElement is textarea
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html (0 => 243044)
--- trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html (rev 0)
+++ trunk/LayoutTests/fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html 2019-03-16 21:17:40 UTC (rev 243044)
@@ -0,0 +1,43 @@
+<!DOCTYPE html>
+<html>
+<head>
+<script src=""
+<script src=""
+<style>
+html, body {
+ width: 100%;
+ height: 100%;
+ margin: 0;
+}
+
+textarea {
+ width: 100%;
+ height: 100px;
+ font-size: 50px;
+ text-align: center;
+}
+</style>
+</head>
+<body>
+ <textarea></textarea>
+ <pre id="description"></pre>
+ <pre id="console"></pre>
+</body>
+<script>
+ jsTestIsAsync = true;
+ textarea = document.querySelector("textarea");
+
+ description("Verifies that the keyboard shows up even after preventing default on touchstart. To manually test, tap the textarea; the textarea should remain focused, and the keyboard should appear.");
+
+ textarea.addEventListener("touchstart", event => event.preventDefault());
+ addEventListener("load", async () => {
+ textarea.focus();
+ await UIHelper.activateElementAndWaitForInputSession(textarea);
+ testPassed("keyboard was shown.");
+ shouldBe("document.activeElement", "textarea");
+ textarea.blur();
+ await UIHelper.waitForKeyboardToHide();
+ finishJSTest();
+ });
+</script>
+</html>
Modified: trunk/Source/WebKit/ChangeLog (243043 => 243044)
--- trunk/Source/WebKit/ChangeLog 2019-03-16 19:54:18 UTC (rev 243043)
+++ trunk/Source/WebKit/ChangeLog 2019-03-16 21:17:40 UTC (rev 243044)
@@ -1,3 +1,46 @@
+2019-03-16 Wenson Hsieh <[email protected]>
+
+ [iOS] Software keyboard never appears when editing on some websites
+ https://bugs.webkit.org/show_bug.cgi?id=195824
+ <rdar://problem/48020610>
+
+ Reviewed by Ryosuke Niwa.
+
+ In the scenario where an element has already been programmatically focused but the UI process isn't showing an
+ input view for it, there are a couple of different ways in which an input view may still be shown for that
+ element:
+
+ 1. If the page attempts to programmatically focus the element, we'll invoke elementDidRefocus to recompute
+ information about the focused element and propagate it to the UI process. By default, if programmatic focus was
+ triggered under the scope of user interaction, we'll allow the input view to appear.
+
+ 2. In the case where page does not attempt to programmatically focus the element but a click is dispatched,
+ there is logic in WebPage::completeSyntheticClick to send information about the already-focused element.
+
+ On the web page relevant to this bug, focus is programmatically moved to hidden contenteditable areas upon page
+ load, and touchstart is also prevented; furthermore, the page does not attempt to programmatically refocus the
+ hidden editable area upon receiving touchstart. This means that the user will never be able to bring up the
+ keyboard, since the editable area is already programmatically focused and subsequent attempts to tap in the
+ page do nothing, because the page has already focused the hidden editable area (with the expectation that the
+ software keyboard should already be present).
+
+ To fix this, we bring some of the same logic in completeSyntheticClick over to dispatchTouchEvent, by sending
+ focused element information to the UI process if the focused element did not change over the course of
+ dispatching the touch event. Similar code was introduced in r167774 to fix the same type of issue (i.e.
+ inability to bring up the software keyboard), but this was later reverted in r188405 due to causing bugs such as
+ <rdar://problem/22204108>, wherein this logic to bring up the keyboard in dispatchTouchEvent would scroll and
+ zoom the page, such that the click event fired after touchend would be dispatched in the wrong location and (in
+ the case of <rdar://problem/22204108>) caused the focused element to immediately blur again.
+
+ To mitigate this issue, we add the additional constraint that we only send focused element info in the case
+ where the touch won't also generate a click later down the road, by requiring that the dispatched event was
+ handled by the page (i.e. prevented).
+
+ Test: fast/events/touch/ios/show-keyboard-after-preventing-touchstart.html
+
+ * WebProcess/WebPage/WebPage.cpp:
+ (WebKit::WebPage::dispatchTouchEvent):
+
2019-03-16 Zalan Bujtas <[email protected]>
Unable to close trending window on naver.com.
Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp (243043 => 243044)
--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-03-16 19:54:18 UTC (rev 243043)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-03-16 21:17:40 UTC (rev 243044)
@@ -2817,10 +2817,20 @@
{
SetForScope<bool> userIsInteractingChange { m_userIsInteracting, true };
+ auto oldFocusedFrame = makeRefPtr(m_page->focusController().focusedFrame());
+ auto oldFocusedElement = makeRefPtr(oldFocusedFrame ? oldFocusedFrame->document()->focusedElement() : nullptr);
+
m_lastInteractionLocation = touchEvent.position();
CurrentEvent currentEvent(touchEvent);
handled = handleTouchEvent(touchEvent, m_page.get());
updatePotentialTapSecurityOrigin(touchEvent, handled);
+
+ if (handled && oldFocusedElement) {
+ auto newFocusedFrame = makeRefPtr(m_page->focusController().focusedFrame());
+ auto newFocusedElement = makeRefPtr(newFocusedFrame ? newFocusedFrame->document()->focusedElement() : nullptr);
+ if (oldFocusedElement == newFocusedElement)
+ elementDidRefocus(*newFocusedElement);
+ }
}
void WebPage::touchEventSync(const WebTouchEvent& touchEvent, CompletionHandler<void(bool)>&& reply)
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
