Diff
Modified: branches/safari-608.1.24-branch/LayoutTests/ChangeLog (245224 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/ChangeLog 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/LayoutTests/ChangeLog 2019-05-13 06:51:02 UTC (rev 245225)
@@ -1,3 +1,81 @@
+2019-05-12 Babak Shafiei <[email protected]>
+
+ Cherry-pick r245144. rdar://problem/47902054
+
+ [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
+ https://bugs.webkit.org/show_bug.cgi?id=197632
+ <rdar://problem/47902054>
+
+ Reviewed by Brent Fulgham.
+
+ Source/WebKit:
+
+ Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
+ opens a new window.
+
+ By default we only allow popups to open if they were user initiated (like when a person clicks
+ on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
+ WebCore processes an event from WebKit. So long as this token is on the stack we consider
+ all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
+ the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
+ part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
+ However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
+ with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
+ to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
+ and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
+ to determine if it's being called by the keyboard. If it is then we can assume that this is
+ part of key event handling and hence was initiated by the user. We can pass along this detail
+ to the WebProcess for it to push a new UserGestureToken onto the stack.
+
+ For now we only track whether text inserted by the keyboard was user initiated or not. In
+ <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
+
+ * Platform/spi/ios/UIKitSPI.h: Expose SPI.
+ * Shared/Cocoa/InsertTextOptions.cpp:
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
+ Encode and decode whether we are processing a user gesture.
+
+ * Shared/Cocoa/InsertTextOptions.h:
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
+ the embedding client did. We only want to privilege user initiated actions (the keyboard).
+ * WebProcess/WebPage/WebPage.cpp:
+ (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
+ depending on whether we are or are not processing a user gesture.
+
+ LayoutTests:
+
+ Add tests to ensure we fire input and keypress events in the correct order and that we can
+ submit a <form> with target = "_blank" using the Return key.
+
+ * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
+ * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
+ * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
+ in <rdar://problem/50596032>.
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2019-05-09 Daniel Bates <[email protected]>
+
+ [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
+ https://bugs.webkit.org/show_bug.cgi?id=197632
+ <rdar://problem/47902054>
+
+ Reviewed by Brent Fulgham.
+
+ Add tests to ensure we fire input and keypress events in the correct order and that we can
+ submit a <form> with target = "_blank" using the Return key.
+
+ * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
+ * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
+ * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
+ in <rdar://problem/50596032>.
+
2019-05-09 Antti Koivisto <[email protected]>
Elements with "display: inline-block" don't have a touch-action region
Added: branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt (0 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt (rev 0)
+++ branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt 2019-05-13 06:51:02 UTC (rev 245225)
@@ -0,0 +1,11 @@
+Tests that pressing the Return key in a content editable elemnent dispatches a DOM input event and DOM keypress event (in that order). To run this test by hand, focus the content editable element below and press the Return key.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+PASS event.key is "Enter"
+PASS event.inputType is "insertParagraph"
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key.html (0 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key.html (rev 0)
+++ branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/fire-input-and-keypress-on-return-key.html 2019-05-13 06:51:02 UTC (rev 245225)
@@ -0,0 +1,49 @@
+<!DOCTYPE html>
+<html>
+<head>
+<script src=""
+<script src=""
+</head>
+<body>
+<p id="description"></p>
+<div id="test" contenteditable="true" style="width:256px; height: 256px; border: 1px solid black"></div>
+<div id="console"></div>
+<script>
+window.jsTestIsAsync = true;
+
+function done()
+{
+ document.body.removeChild(document.getElementById("test"));
+ finishJSTest();
+}
+
+function checkInputEvent()
+{
+ shouldBeEqualToString("event.inputType", "insertParagraph");
+ done();
+}
+
+function checkKeypressAndDone()
+{
+ shouldBeEqualToString("event.key", "Enter");
+}
+
+function runTest()
+{
+ function handleFocus(event) {
+ event.target.addEventListener("input", checkInputEvent, { once: true });
+ event.target.addEventListener("keypress", checkKeypressAndDone, { once: true });
+ if (window.testRunner)
+ UIHelper.keyDown("return");
+ }
+ let test = document.getElementById("test");
+ test.addEventListener("focus", handleFocus, { once: true });
+ if (window.testRunner)
+ UIHelper.activateElement(test);
+}
+
+description("Tests that pressing the Return key in a content editable elemnent dispatches a DOM input event and DOM keypress event (in that order). To run this test by hand, focus the content editable element below and press the <key>Return<key> key.");
+runTest();
+</script>
+</body>
+</html>
Added: branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key-expected.txt (0 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key-expected.txt (rev 0)
+++ branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key-expected.txt 2019-05-13 06:51:02 UTC (rev 245225)
@@ -0,0 +1,10 @@
+Tests that pressing the Return key in a text field with an associated form implicitly submits the form. To run this test by hand, focus the text field below and press the Return key.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+PASS event.key is "Enter"
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key.html (0 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key.html (rev 0)
+++ branches/safari-608.1.24-branch/LayoutTests/fast/events/ios/submit-form-target-blank-using-return-key.html 2019-05-13 06:51:02 UTC (rev 245225)
@@ -0,0 +1,57 @@
+<!DOCTYPE html>
+<html>
+<head>
+<script src=""
+<script src=""
+</head>
+<body>
+<p id="description"></p>
+<form action="" target="_blank">
+ <input type="text" id="test">
+</form>
+<div id="console"></div>
+<script>
+window.jsTestIsAsync = true;
+
+if (window.testRunner) {
+ testRunner.setCanOpenWindows(true);
+ testRunner.setCloseRemainingWindowsWhenComplete(true);
+ testRunner.setPopupBlockingEnabled(true);
+}
+
+function done()
+{
+ document.body.removeChild(document.querySelector("form"));
+ finishJSTest();
+}
+
+function checkInputEvent()
+{
+ testFailed("Should not have dispatched input event.");
+ done();
+}
+
+function checkKeypressAndDone()
+{
+ shouldBeEqualToString("event.key", "Enter");
+}
+
+function runTest()
+{
+ function handleFocus(event) {
+ event.target.addEventListener("input", checkInputEvent, { once: true });
+ event.target.addEventListener("keypress", checkKeypressAndDone, { once: true });
+ if (window.testRunner)
+ UIHelper.keyDown("return");
+ }
+ let test = document.getElementById("test");
+ test.addEventListener("focus", handleFocus, { once: true });
+ if (window.testRunner)
+ UIHelper.activateElement(test);
+}
+
+description("Tests that pressing the Return key in a text field with an associated form implicitly submits the form. To run this test by hand, focus the text field below and press the <key>Return<key> key.");
+runTest();
+</script>
+</body>
+</html>
Modified: branches/safari-608.1.24-branch/LayoutTests/platform/ios/TestExpectations (245224 => 245225)
--- branches/safari-608.1.24-branch/LayoutTests/platform/ios/TestExpectations 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/LayoutTests/platform/ios/TestExpectations 2019-05-13 06:51:02 UTC (rev 245225)
@@ -3261,3 +3261,6 @@
webkit.org/b/197473 imported/w3c/web-platform-tests/resource-timing/resource-timing-level1.sub.html [ Pass Failure ]
webkit.org/b/175678 media/W3C/video/events/event_progress.html [ Pass Failure ]
+
+# FIXME: Unskip the following test once we have the fix for <rdar://problem/50596032>.
+fast/events/ios/submit-form-target-blank-using-return-key.html
Modified: branches/safari-608.1.24-branch/Source/WebKit/ChangeLog (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/ChangeLog 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/ChangeLog 2019-05-13 06:51:02 UTC (rev 245225)
@@ -1,3 +1,105 @@
+2019-05-12 Babak Shafiei <[email protected]>
+
+ Cherry-pick r245144. rdar://problem/47902054
+
+ [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
+ https://bugs.webkit.org/show_bug.cgi?id=197632
+ <rdar://problem/47902054>
+
+ Reviewed by Brent Fulgham.
+
+ Source/WebKit:
+
+ Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
+ opens a new window.
+
+ By default we only allow popups to open if they were user initiated (like when a person clicks
+ on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
+ WebCore processes an event from WebKit. So long as this token is on the stack we consider
+ all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
+ the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
+ part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
+ However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
+ with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
+ to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
+ and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
+ to determine if it's being called by the keyboard. If it is then we can assume that this is
+ part of key event handling and hence was initiated by the user. We can pass along this detail
+ to the WebProcess for it to push a new UserGestureToken onto the stack.
+
+ For now we only track whether text inserted by the keyboard was user initiated or not. In
+ <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
+
+ * Platform/spi/ios/UIKitSPI.h: Expose SPI.
+ * Shared/Cocoa/InsertTextOptions.cpp:
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
+ Encode and decode whether we are processing a user gesture.
+
+ * Shared/Cocoa/InsertTextOptions.h:
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
+ the embedding client did. We only want to privilege user initiated actions (the keyboard).
+ * WebProcess/WebPage/WebPage.cpp:
+ (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
+ depending on whether we are or are not processing a user gesture.
+
+ LayoutTests:
+
+ Add tests to ensure we fire input and keypress events in the correct order and that we can
+ submit a <form> with target = "_blank" using the Return key.
+
+ * fast/events/ios/fire-input-and-keypress-on-return-key-expected.txt: Added.
+ * fast/events/ios/fire-input-and-keypress-on-return-key.html: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key-expected.txt: Added.
+ * fast/events/ios/submit-form-target-blank-using-return-key.html: Added.
+ * platform/ios/TestExpectations: Skip the test until we have the UIKit SPI added
+ in <rdar://problem/50596032>.
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2019-05-09 Daniel Bates <[email protected]>
+
+ [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
+ https://bugs.webkit.org/show_bug.cgi?id=197632
+ <rdar://problem/47902054>
+
+ Reviewed by Brent Fulgham.
+
+ Fixes an issue where it is not possible to submit a <form> with target = "_blank": a form that
+ opens a new window.
+
+ By default we only allow popups to open if they were user initiated (like when a person clicks
+ on a link). We achieve this by putting a token on the stack, called the UserGestureToken when
+ WebCore processes an event from WebKit. So long as this token is on the stack we consider
+ all requests to open a popup to be user initiated. And we implicitly submit a form when pressing
+ the Return key in an HTML input element during the processing of a TextInputEvent dispatched as
+ part of inserting a '\n' into the field. On Mac, the keydown dispatches a TextInputEvent synchronously.
+ However on iOS text insertion, and hence a dispatch of a TextInputEvent event, occurs asynchronously
+ with respect to the keydown event. So, by the time the UI process calls back to the WebProcess
+ to perform the text insertion of '\n' we have long since popped the UserGestureToken off the stack
+ and hence we disallow opening a popup. To fix this, when -insertText is called we query the keyboard
+ to determine if it's being called by the keyboard. If it is then we can assume that this is
+ part of key event handling and hence was initiated by the user. We can pass along this detail
+ to the WebProcess for it to push a new UserGestureToken onto the stack.
+
+ For now we only track whether text inserted by the keyboard was user initiated or not. In
+ <https://bugs.webkit.org/show_bug.cgi?id=197721> we will fix this up for all editing commands.
+
+ * Platform/spi/ios/UIKitSPI.h: Expose SPI.
+ * Shared/Cocoa/InsertTextOptions.cpp:
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::encode):
+ (IPC::ArgumentCoder<WebKit::InsertTextOptions>::decode):
+ Encode and decode whether we are processing a user gesture.
+
+ * Shared/Cocoa/InsertTextOptions.h:
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView insertText:]): Query the keyboard to determine whether it called us or
+ the embedding client did. We only want to privilege user initiated actions (the keyboard).
+ * WebProcess/WebPage/WebPage.cpp:
+ (WebKit::WebPage::insertTextAsync): Push a UserGestureToken onto the stack that is initialized
+ depending on whether we are or are not processing a user gesture.
+
2019-05-08 Antoine Quint <[email protected]>
[iOS] Correctly handle overlapping regions for elements with a touch-action property
Modified: branches/safari-608.1.24-branch/Source/WebKit/Platform/spi/ios/UIKitSPI.h (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/Platform/spi/ios/UIKitSPI.h 2019-05-13 06:51:02 UTC (rev 245225)
@@ -1126,6 +1126,7 @@
- (BOOL)handleKeyTextCommandForCurrentEvent;
- (BOOL)handleKeyAppCommandForCurrentEvent;
- (BOOL)handleKeyInputMethodCommandForCurrentEvent;
+- (BOOL)isCallingInputDelegate;
@property (nonatomic, readonly) UIKeyboardInputMode *currentInputModeInPreference;
@end
Modified: branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.cpp (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.cpp 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.cpp 2019-05-13 06:51:02 UTC (rev 245225)
@@ -32,6 +32,7 @@
{
encoder << options.registerUndoGroup;
encoder << options.suppressSelectionUpdate;
+ encoder << options.processingUserGesture;
encoder << options.editingRangeIsRelativeTo;
}
@@ -42,6 +43,8 @@
return WTF::nullopt;
if (!decoder.decode(options.suppressSelectionUpdate))
return WTF::nullopt;
+ if (!decoder.decode(options.processingUserGesture))
+ return WTF::nullopt;
if (!decoder.decode(options.editingRangeIsRelativeTo))
return WTF::nullopt;
return options;
Modified: branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.h (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.h 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/Shared/Cocoa/InsertTextOptions.h 2019-05-13 06:51:02 UTC (rev 245225)
@@ -33,6 +33,7 @@
struct InsertTextOptions {
bool registerUndoGroup { false };
bool suppressSelectionUpdate { false };
+ bool processingUserGesture { false };
EditingRangeIsRelativeTo editingRangeIsRelativeTo { EditingRangeIsRelativeTo::EditableRoot };
};
Modified: branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-05-13 06:51:02 UTC (rev 245225)
@@ -4179,7 +4179,12 @@
// Inserts the given string, replacing any selected or marked text.
- (void)insertText:(NSString *)aStringValue
{
- _page->insertTextAsync(aStringValue, WebKit::EditingRange(), { });
+ auto* keyboard = [UIKeyboardImpl sharedInstance];
+
+ WebKit::InsertTextOptions options;
+ options.processingUserGesture = [keyboard respondsToSelector:@selector(isCallingInputDelegate)] && keyboard.isCallingInputDelegate;
+
+ _page->insertTextAsync(aStringValue, WebKit::EditingRange(), WTFMove(options));
}
- (BOOL)hasText
@@ -4671,6 +4676,9 @@
- (void)executeEditCommandWithCallback:(NSString *)commandName
{
+ // FIXME: Editing commands are not considered by WebKit as user initiated even if they are the result
+ // of keydown or keyup. We need to query the keyboard to determine if this was called from the keyboard
+ // or not to know whether to tell WebKit to treat this command as user initiated or not.
[self beginSelectionChange];
RetainPtr<WKContentView> view = self;
_page->executeEditCommand(commandName, { }, [view](WebKit::CallbackBase::Error) {
Modified: branches/safari-608.1.24-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp (245224 => 245225)
--- branches/safari-608.1.24-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-05-13 06:30:07 UTC (rev 245224)
+++ branches/safari-608.1.24-branch/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-05-13 06:51:02 UTC (rev 245225)
@@ -5135,6 +5135,8 @@
Ref<Frame> protector(frame);
+ UserGestureIndicator gestureIndicator { options.processingUserGesture ? ProcessingUserGesture : NotProcessingUserGesture, frame.document() };
+
bool replacesText = false;
if (replacementEditingRange.location != notFound) {
if (auto replacementRange = EditingRange::toRange(frame, replacementEditingRange, options.editingRangeIsRelativeTo)) {
