- Revision
- 242833
- Author
- [email protected]
- Date
- 2019-03-12 16:51:57 -0700 (Tue, 12 Mar 2019)
Log Message
[iOS] Input view sometimes flickers when blurring and refocusing an element
https://bugs.webkit.org/show_bug.cgi?id=195639
<rdar://problem/48735337>
Reviewed by Tim Horton.
Source/WebKit:
On iOS, if a focused element is blurred and immediately refocused in the scope of user interaction, we will end
up reloading interaction state (input views, autocorrection contexts, etc.) in the UI process. On certain well-
trafficked websites, this results in the input view and input accessory view flickering (or more egregiously,
scrolling to re-reveal the focused element) when changing selection.
To fix the issue, this patch refactors some focus management logic to suppress sending focused element updates
to the UI process in the case where the same element is being blurred and immediately refocused. To do this, we
track the most recently blurred element and bail when the recently blurred element is identical to the newly
focused element. See below for more detail.
Test: fast/forms/ios/keyboard-stability-when-refocusing-element.html
* UIProcess/WebPageProxy.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
(-[WKContentView _elementDidBlur]):
Update the web process' notion of whether an input view is showing. Importantly, this accounts for decisions
made by _WKUIDelegate. See below for more details.
(isAssistableInputType): Deleted.
Removed this helper function; this was only used in one place as a sanity check that the focused element's type
is not none, right before attempting to show an input view. Instead, we can just check the focused element's
type directly against InputType::None in the if statement of the early return.
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::setIsShowingInputViewForFocusedElement):
Add a hook to notify the web process when an input view is showing or not (see below for more detail).
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didStartPageTransition):
(WebKit::WebPage::elementDidRefocus):
(WebKit::WebPage::shouldDispatchUpdateAfterFocusingElement const):
Add a helper to determine whether we notify the UI process about a newly focused element. On macOS, this is true
only when the new focused element is neither the currently focused element, nor the focused element that was
just blurred. On iOS, we have an additional constraint that when the input view is not showing, we still need to
notify the UI process, since the UI process might want to begin showing the keyboard for an element that has
only been programmatically focused, for which we aren't currently showing the input view.
(WebKit::WebPage::elementDidFocus):
(WebKit::WebPage::elementDidBlur):
Replace a couple of existing member variables in WebPage used for focus management:
- Replace m_hasPendingBlurNotification with m_recentlyBlurredElement, a RefPtr to the Element that is being
blurred. Behavior here is the same as before (i.e. having a pending blur notification is equivalent to
having recently blurred a focused element). However, this allows us to check newly focused elements against
the recently blurred element in WebPage::elementDidFocus().
- Replace m_isFocusingElementDueToUserInteraction with m_isShowingInputViewForFocusedElement. The flag
m_isFocusingElementDueToUserInteraction was originally added to fix <webkit.org/b/146735>, by ensuring that
we don't send redundant ElementDidFocus (formerly, StartAssistingNode) messages to the UI process even when
the keyboard is already up. In these simpler times, user interaction when focusing an element was equivalent
to showing an input view for the focused element. However, in today's world, there are a variety of reasons
why we might or might not show an input view for a given element (including, but not limited to activity
state changes and decisions made by _WKInputDelegate). As such, it doesn't make sense to continue relying on
m_isFocusingElementDueToUserInteraction in this early return. Instead, have the UI process propagate a
message back to the web process, to let it know whether there is a keyboard showing, and use this flag
instead.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::setIsShowingInputViewForFocusedElement):
LayoutTests:
Add a test to ensure that the form control interaction doesn't stop and start again when blurring and focusing
an editable element.
* fast/forms/ios/keyboard-stability-when-refocusing-element-expected.txt: Added.
* fast/forms/ios/keyboard-stability-when-refocusing-element.html: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (242832 => 242833)
--- trunk/LayoutTests/ChangeLog 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/LayoutTests/ChangeLog 2019-03-12 23:51:57 UTC (rev 242833)
@@ -1,3 +1,17 @@
+2019-03-12 Wenson Hsieh <[email protected]>
+
+ [iOS] Input view sometimes flickers when blurring and refocusing an element
+ https://bugs.webkit.org/show_bug.cgi?id=195639
+ <rdar://problem/48735337>
+
+ Reviewed by Tim Horton.
+
+ Add a test to ensure that the form control interaction doesn't stop and start again when blurring and focusing
+ an editable element.
+
+ * fast/forms/ios/keyboard-stability-when-refocusing-element-expected.txt: Added.
+ * fast/forms/ios/keyboard-stability-when-refocusing-element.html: Added.
+
2019-03-12 Dean Jackson <[email protected]>
[WebGL] WebGLBuffer can be too large
Added: trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element-expected.txt (0 => 242833)
--- trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element-expected.txt 2019-03-12 23:51:57 UTC (rev 242833)
@@ -0,0 +1,9 @@
+Verifies that input view state doesn't thrash when script blurs and immediately refocuses an editable element. To manually run the test, tap the red editable box to focus it, and then tap the box again; check that the keyboard and input accessory view do not flicker, and that the scroll position remains the same.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+PASS result is "Ended"
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element.html (0 => 242833)
--- trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element.html (rev 0)
+++ trunk/LayoutTests/fast/forms/ios/keyboard-stability-when-refocusing-element.html 2019-03-12 23:51:57 UTC (rev 242833)
@@ -0,0 +1,103 @@
+<!DOCTYPE html> <!-- webkit-test-runner [ useFlexibleViewport=true ] -->
+<html>
+<head>
+<script src=""
+<script src=""
+<meta name=viewport content="width=device-width, initial-scale=1, user-scalable=no">
+<style>
+body, html {
+ width: 100%;
+ height: 1000px;
+ margin: 0;
+}
+
+#editor {
+ width: 100%;
+ height: 50px;
+ border: 2px red solid;
+ font-size: 40px;
+ text-align: center;
+}
+
+#container {
+ width: 100%;
+ height: 54px;
+ border: 2px black solid;
+ position: absolute;
+ top: 50px;
+}
+</style>
+</head>
+<body>
+<div id="editor" contenteditable></div>
+<div id="container"></div>
+<pre id="description"></pre>
+<pre id="console"></pre>
+</body>
+<script>
+jsTestIsAsync = true;
+
+description("Verifies that input view state doesn't thrash when script blurs and immediately refocuses an editable element. To manually run the test, tap the red editable box to focus it, and then tap the box again; check that the keyboard and input accessory view do not flicker, and that the scroll position remains the same.");
+
+container = document.getElementById("container");
+editor = document.getElementById("editor");
+editor.addEventListener("mousedown", event => {
+ if (document.activeElement !== editor)
+ return;
+
+ editor.remove();
+ container.appendChild(editor);
+ editor.focus();
+ event.preventDefault();
+});
+
+addEventListener("load", async () => {
+ if (!window.testRunner)
+ return;
+
+ await UIHelper.activateAndWaitForInputSessionAt(160, 40);
+ testRunner.runUIScript(`
+ let startedFormControlInteraction = false;
+ let endedFormControlInteraction = false;
+
+ function scheduleUIScriptCompletion() {
+ if (startedFormControlInteraction || endedFormControlInteraction)
+ return;
+
+ uiController.doAsyncTask(() => {
+ uiController.didStartFormControlInteractionCallback = null;
+ uiController.didEndFormControlInteractionCallback = null;
+
+ let result = null;
+ if (startedFormControlInteraction && endedFormControlInteraction)
+ result = "Started, Ended";
+ else if (startedFormControlInteraction)
+ result = "Started";
+ else if (endedFormControlInteraction)
+ result = "Ended";
+
+ uiController.uiScriptComplete(result);
+ });
+ }
+
+ uiController.didStartFormControlInteractionCallback = () => {
+ scheduleUIScriptCompletion();
+ startedFormControlInteraction = true;
+ };
+
+ uiController.didEndFormControlInteractionCallback = () => {
+ scheduleUIScriptCompletion();
+ endedFormControlInteraction = true;
+ };
+
+ uiController.singleTapAtPoint(160, 40, () => uiController.resignFirstResponder());
+ `, checkResultAndFinishTest);
+});
+
+function checkResultAndFinishTest(result) {
+ window.result = result;
+ shouldBeEqualToString("result", "Ended");
+ finishJSTest();
+}
+</script>
+</html>
Modified: trunk/Source/WebKit/ChangeLog (242832 => 242833)
--- trunk/Source/WebKit/ChangeLog 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/ChangeLog 2019-03-12 23:51:57 UTC (rev 242833)
@@ -1,3 +1,77 @@
+2019-03-12 Wenson Hsieh <[email protected]>
+
+ [iOS] Input view sometimes flickers when blurring and refocusing an element
+ https://bugs.webkit.org/show_bug.cgi?id=195639
+ <rdar://problem/48735337>
+
+ Reviewed by Tim Horton.
+
+ On iOS, if a focused element is blurred and immediately refocused in the scope of user interaction, we will end
+ up reloading interaction state (input views, autocorrection contexts, etc.) in the UI process. On certain well-
+ trafficked websites, this results in the input view and input accessory view flickering (or more egregiously,
+ scrolling to re-reveal the focused element) when changing selection.
+
+ To fix the issue, this patch refactors some focus management logic to suppress sending focused element updates
+ to the UI process in the case where the same element is being blurred and immediately refocused. To do this, we
+ track the most recently blurred element and bail when the recently blurred element is identical to the newly
+ focused element. See below for more detail.
+
+ Test: fast/forms/ios/keyboard-stability-when-refocusing-element.html
+
+ * UIProcess/WebPageProxy.h:
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):
+ (-[WKContentView _elementDidBlur]):
+
+ Update the web process' notion of whether an input view is showing. Importantly, this accounts for decisions
+ made by _WKUIDelegate. See below for more details.
+
+ (isAssistableInputType): Deleted.
+
+ Removed this helper function; this was only used in one place as a sanity check that the focused element's type
+ is not none, right before attempting to show an input view. Instead, we can just check the focused element's
+ type directly against InputType::None in the if statement of the early return.
+
+ * UIProcess/ios/WebPageProxyIOS.mm:
+ (WebKit::WebPageProxy::setIsShowingInputViewForFocusedElement):
+
+ Add a hook to notify the web process when an input view is showing or not (see below for more detail).
+
+ * WebProcess/WebPage/WebPage.cpp:
+ (WebKit::WebPage::didStartPageTransition):
+ (WebKit::WebPage::elementDidRefocus):
+ (WebKit::WebPage::shouldDispatchUpdateAfterFocusingElement const):
+
+ Add a helper to determine whether we notify the UI process about a newly focused element. On macOS, this is true
+ only when the new focused element is neither the currently focused element, nor the focused element that was
+ just blurred. On iOS, we have an additional constraint that when the input view is not showing, we still need to
+ notify the UI process, since the UI process might want to begin showing the keyboard for an element that has
+ only been programmatically focused, for which we aren't currently showing the input view.
+
+ (WebKit::WebPage::elementDidFocus):
+ (WebKit::WebPage::elementDidBlur):
+
+ Replace a couple of existing member variables in WebPage used for focus management:
+ - Replace m_hasPendingBlurNotification with m_recentlyBlurredElement, a RefPtr to the Element that is being
+ blurred. Behavior here is the same as before (i.e. having a pending blur notification is equivalent to
+ having recently blurred a focused element). However, this allows us to check newly focused elements against
+ the recently blurred element in WebPage::elementDidFocus().
+ - Replace m_isFocusingElementDueToUserInteraction with m_isShowingInputViewForFocusedElement. The flag
+ m_isFocusingElementDueToUserInteraction was originally added to fix <webkit.org/b/146735>, by ensuring that
+ we don't send redundant ElementDidFocus (formerly, StartAssistingNode) messages to the UI process even when
+ the keyboard is already up. In these simpler times, user interaction when focusing an element was equivalent
+ to showing an input view for the focused element. However, in today's world, there are a variety of reasons
+ why we might or might not show an input view for a given element (including, but not limited to activity
+ state changes and decisions made by _WKInputDelegate). As such, it doesn't make sense to continue relying on
+ m_isFocusingElementDueToUserInteraction in this early return. Instead, have the UI process propagate a
+ message back to the web process, to let it know whether there is a keyboard showing, and use this flag
+ instead.
+
+ * WebProcess/WebPage/WebPage.h:
+ * WebProcess/WebPage/WebPage.messages.in:
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::WebPage::setIsShowingInputViewForFocusedElement):
+
2019-03-12 Tim Horton <[email protected]>
More attempts at build fixing.
Modified: trunk/Source/WebKit/UIProcess/WebPageProxy.h (242832 => 242833)
--- trunk/Source/WebKit/UIProcess/WebPageProxy.h 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/UIProcess/WebPageProxy.h 2019-03-12 23:51:57 UTC (rev 242833)
@@ -1194,6 +1194,7 @@
void inspectorNodeSearchEndedAtPosition(const WebCore::FloatPoint&);
void blurFocusedElement();
+ void setIsShowingInputViewForFocusedElement(bool);
#endif
void postMessageToInjectedBundle(const String& messageName, API::Object* messageBody);
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (242832 => 242833)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-03-12 23:51:57 UTC (rev 242833)
@@ -4817,40 +4817,6 @@
return selectionBoundingRect;
}
-static bool isAssistableInputType(WebKit::InputType type)
-{
- switch (type) {
- case WebKit::InputType::ContentEditable:
- case WebKit::InputType::Text:
- case WebKit::InputType::Password:
- case WebKit::InputType::TextArea:
- case WebKit::InputType::Search:
- case WebKit::InputType::Email:
- case WebKit::InputType::URL:
- case WebKit::InputType::Phone:
- case WebKit::InputType::Number:
- case WebKit::InputType::NumberPad:
- case WebKit::InputType::Date:
- case WebKit::InputType::DateTime:
- case WebKit::InputType::DateTimeLocal:
- case WebKit::InputType::Month:
- case WebKit::InputType::Week:
- case WebKit::InputType::Time:
- case WebKit::InputType::Select:
- case WebKit::InputType::Drawing:
-#if ENABLE(INPUT_TYPE_COLOR)
- case WebKit::InputType::Color:
-#endif
- return true;
-
- case WebKit::InputType::None:
- return false;
- }
-
- ASSERT_NOT_REACHED();
- return false;
-}
-
static const double minimumFocusedElementAreaForSuppressingSelectionAssistant = 4;
- (void)_elementDidFocus:(const WebKit::FocusedElementInformation&)information userIsInteracting:(BOOL)userIsInteracting blurPreviousNode:(BOOL)blurPreviousNode changingActivityState:(BOOL)changingActivityState userObject:(NSObject <NSSecureCoding> *)userObject
@@ -4933,11 +4899,12 @@
[_drawingCoordinator installInkPickerForDrawing:information.embeddedViewID];
#endif
- if (!shouldShowInputView)
+ if (!shouldShowInputView || information.elementType == WebKit::InputType::None) {
+ _page->setIsShowingInputViewForFocusedElement(false);
return;
+ }
- if (!isAssistableInputType(information.elementType))
- return;
+ _page->setIsShowingInputViewForFocusedElement(true);
// FIXME: We should remove this check when we manage to send ElementDidFocus from the WebProcess
// only when it is truly time to show the keyboard.
@@ -5056,6 +5023,7 @@
[_webView _scheduleVisibleContentRectUpdate];
[_webView didEndFormControlInteraction];
+ _page->setIsShowingInputViewForFocusedElement(false);
if (!_isChangingFocus) {
[self _stopSuppressingSelectionAssistantForReason:WebKit::FocusedElementIsTransparentOrFullyClipped];
Modified: trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm (242832 => 242833)
--- trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm 2019-03-12 23:51:57 UTC (rev 242833)
@@ -898,6 +898,11 @@
pageClient().didGetTapHighlightGeometries(requestID, color, highlightedQuads, topLeftRadius, topRightRadius, bottomLeftRadius, bottomRightRadius, nodeHasBuiltInClickHandling);
}
+void WebPageProxy::setIsShowingInputViewForFocusedElement(bool showingInputView)
+{
+ process().send(Messages::WebPage::SetIsShowingInputViewForFocusedElement(showingInputView), m_pageID);
+}
+
void WebPageProxy::elementDidFocus(const FocusedElementInformation& information, bool userIsInteracting, bool blurPreviousNode, bool changingActivityState, const UserData& userData)
{
m_waitingForPostLayoutEditorStateUpdateAfterFocusingElement = true;
Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp (242832 => 242833)
--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.cpp 2019-03-12 23:51:57 UTC (rev 242833)
@@ -3124,7 +3124,6 @@
bool hasPreviouslyFocusedDueToUserInteraction = m_hasEverFocusedElementDueToUserInteractionSincePageTransition;
#endif
m_hasEverFocusedElementDueToUserInteractionSincePageTransition = false;
- m_isFocusingElementDueToUserInteraction = false;
m_lastEditorStateWasContentEditable = EditorStateIsContentEditable::Unset;
#if PLATFORM(MAC)
if (hasPreviouslyFocusedDueToUserInteraction)
@@ -3138,6 +3137,9 @@
send(Messages::WebPageProxy::SetNeedsPlainTextQuirk(m_needsPlainTextQuirk));
}
#endif
+#if PLATFORM(IOS_FAMILY)
+ m_isShowingInputViewForFocusedElement = false;
+#endif
}
void WebPage::didCompletePageTransition()
@@ -5303,18 +5305,32 @@
{
elementDidFocus(element);
- if (m_isFocusingElementDueToUserInteraction)
+ if (m_userIsInteracting)
scheduleFullEditorStateUpdate();
}
+bool WebPage::shouldDispatchUpdateAfterFocusingElement(const Element& element) const
+{
+ if (m_focusedElement == &element || m_recentlyBlurredElement == &element) {
+#if PLATFORM(IOS_FAMILY)
+ return !m_isShowingInputViewForFocusedElement;
+#else
+ return false;
+#endif
+ }
+ return true;
+}
+
void WebPage::elementDidFocus(WebCore::Element& element)
{
- if (m_focusedElement == &element && m_isFocusingElementDueToUserInteraction)
+ if (!shouldDispatchUpdateAfterFocusingElement(element)) {
+ m_focusedElement = &element;
+ m_recentlyBlurredElement = nullptr;
return;
+ }
if (element.hasTagName(WebCore::HTMLNames::selectTag) || element.hasTagName(WebCore::HTMLNames::inputTag) || element.hasTagName(WebCore::HTMLNames::textareaTag) || element.hasEditableStyle()) {
m_focusedElement = &element;
- m_isFocusingElementDueToUserInteraction |= m_userIsInteracting;
#if PLATFORM(IOS_FAMILY)
@@ -5330,14 +5346,13 @@
m_formClient->willBeginInputSession(this, &element, WebFrame::fromCoreFrame(*element.document().frame()), m_userIsInteracting, userData);
- send(Messages::WebPageProxy::ElementDidFocus(information, m_userIsInteracting, m_hasPendingBlurNotification, m_changingActivityState, UserData(WebProcess::singleton().transformObjectsToHandles(userData.get()).get())));
+ send(Messages::WebPageProxy::ElementDidFocus(information, m_userIsInteracting, m_recentlyBlurredElement, m_changingActivityState, UserData(WebProcess::singleton().transformObjectsToHandles(userData.get()).get())));
#elif PLATFORM(MAC)
- if (element.hasTagName(WebCore::HTMLNames::selectTag))
- send(Messages::WebPageProxy::SetEditableElementIsFocused(false));
- else
- send(Messages::WebPageProxy::SetEditableElementIsFocused(true));
+ // FIXME: This can be unified with the iOS code above by bringing ElementDidFocus to macOS.
+ // This also doesn't take other noneditable controls into account, such as input type color.
+ send(Messages::WebPageProxy::SetEditableElementIsFocused(!element.hasTagName(WebCore::HTMLNames::selectTag)));
#endif
- m_hasPendingBlurNotification = false;
+ m_recentlyBlurredElement = nullptr;
}
}
@@ -5344,10 +5359,9 @@
void WebPage::elementDidBlur(WebCore::Element& element)
{
if (m_focusedElement == &element) {
- m_hasPendingBlurNotification = true;
- RefPtr<WebPage> protectedThis(this);
- callOnMainThread([protectedThis] {
- if (protectedThis->m_hasPendingBlurNotification) {
+ m_recentlyBlurredElement = WTFMove(m_focusedElement);
+ callOnMainThread([protectedThis = makeRefPtr(this)] {
+ if (protectedThis->m_recentlyBlurredElement) {
#if PLATFORM(IOS_FAMILY)
protectedThis->send(Messages::WebPageProxy::ElementDidBlur());
#elif PLATFORM(MAC)
@@ -5354,11 +5368,8 @@
protectedThis->send(Messages::WebPageProxy::SetEditableElementIsFocused(false));
#endif
}
- protectedThis->m_hasPendingBlurNotification = false;
+ protectedThis->m_recentlyBlurredElement = nullptr;
});
-
- m_isFocusingElementDueToUserInteraction = false;
- m_focusedElement = nullptr;
}
}
Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.h (242832 => 242833)
--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.h 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.h 2019-03-12 23:51:57 UTC (rev 242833)
@@ -658,6 +658,7 @@
void setFocusedElementValue(const String&);
void setFocusedElementValueAsNumber(double);
void setFocusedElementSelectedIndex(uint32_t index, bool allowMultipleSelection);
+ void setIsShowingInputViewForFocusedElement(bool);
void updateSelectionAppearance();
void getSelectionContext(CallbackID);
void handleTwoFingerTapAtPoint(const WebCore::IntPoint&, OptionSet<WebKit::WebEvent::Modifier>, uint64_t requestID);
@@ -1527,6 +1528,8 @@
void cancelGesturesBlockedOnSynchronousReplies();
+ bool shouldDispatchUpdateAfterFocusingElement(const WebCore::Element&) const;
+
uint64_t m_pageID;
std::unique_ptr<WebCore::Page> m_page;
@@ -1724,7 +1727,6 @@
Optional<WebCore::IntSize> m_viewportSizeForCSSViewportUnits;
bool m_userIsInteracting { false };
- bool m_isFocusingElementDueToUserInteraction { false };
bool m_hasEverFocusedElementDueToUserInteractionSincePageTransition { false };
bool m_needsHiddenContentEditableQuirk { false };
bool m_needsPlainTextQuirk { false };
@@ -1735,7 +1737,7 @@
#endif
RefPtr<WebCore::Element> m_focusedElement;
- bool m_hasPendingBlurNotification { false };
+ RefPtr<WebCore::Element> m_recentlyBlurredElement;
bool m_hasPendingEditorStateUpdate { false };
#if ENABLE(IOS_TOUCH_EVENTS)
@@ -1746,6 +1748,8 @@
RefPtr<WebCore::Range> m_currentWordRange;
RefPtr<WebCore::Node> m_interactionNode;
WebCore::IntPoint m_lastInteractionLocation;
+
+ bool m_isShowingInputViewForFocusedElement { false };
enum SelectionAnchor { Start, End };
SelectionAnchor m_selectionAnchor { Start };
Modified: trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in (242832 => 242833)
--- trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/WebProcess/WebPage/WebPage.messages.in 2019-03-12 23:51:57 UTC (rev 242833)
@@ -109,6 +109,7 @@
CancelAutoscroll()
RequestFocusedElementInformation(WebKit::CallbackID callbackID)
HardwareKeyboardAvailabilityChanged(bool keyboardIsAttached)
+ SetIsShowingInputViewForFocusedElement(bool showingInputView)
#endif
SetControlledByAutomation(bool controlled)
Modified: trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (242832 => 242833)
--- trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2019-03-12 22:49:34 UTC (rev 242832)
+++ trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2019-03-12 23:51:57 UTC (rev 242833)
@@ -930,6 +930,11 @@
m_focusedElement->blur();
}
+void WebPage::setIsShowingInputViewForFocusedElement(bool showingInputView)
+{
+ m_isShowingInputViewForFocusedElement = showingInputView;
+}
+
void WebPage::setFocusedElementValue(const String& value)
{
// FIXME: should also handle the case of HTMLSelectElement.
