Inputs with the autofocus attribute cause the keyboard to not deploy
authorwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 3 Aug 2015 19:29:47 +0000 (19:29 +0000)
committerwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 3 Aug 2015 19:29:47 +0000 (19:29 +0000)
https://bugs.webkit.org/show_bug.cgi?id=147555
<rdar://problem/22018044>

Reviewed by Andreas Kling.

Upon submitting a form by pressing "Go" on the keyboard, an <input> on the next page with the
autofocus attribute may become non-interactible. When attempting to tap on the input, nothing
seems to happen. This is because the state of WebPage upon invoking WebPage::elementDidFocus
indicates (incorrectly) that the input element is already focused, and therefore hits an early
return. To solve this, we explicitly reset m_hasFocusedDueToUserInteraction upon transitioning
to a new page.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didStartPageTransition): On iOS, resets m_hasFocusedDueToUserInteraction as
    well. It was previously thought that this would be handled by blur() called on the assisted
    element when submitting a form. However, pressing "Go" on the iOS keyboard is an implicit
    submission and does not trigger a blur event.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@187751 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebKit2/ChangeLog
Source/WebKit2/WebProcess/WebPage/WebPage.cpp

index 8d962e450d0b57eeff3660ee1d3907b98c7fdc8c..5c3e417dfdb3737b98b35056d059b6d5fd9ec9da 100644 (file)
@@ -1,3 +1,24 @@
+2015-08-03  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        Inputs with the autofocus attribute cause the keyboard to not deploy
+        https://bugs.webkit.org/show_bug.cgi?id=147555
+        <rdar://problem/22018044>
+
+        Reviewed by Andreas Kling.
+
+        Upon submitting a form by pressing "Go" on the keyboard, an <input> on the next page with the
+        autofocus attribute may become non-interactible. When attempting to tap on the input, nothing
+        seems to happen. This is because the state of WebPage upon invoking WebPage::elementDidFocus
+        indicates (incorrectly) that the input element is already focused, and therefore hits an early
+        return. To solve this, we explicitly reset m_hasFocusedDueToUserInteraction upon transitioning
+        to a new page.
+
+        * WebProcess/WebPage/WebPage.cpp:
+        (WebKit::WebPage::didStartPageTransition): On iOS, resets m_hasFocusedDueToUserInteraction as
+            well. It was previously thought that this would be handled by blur() called on the assisted
+            element when submitting a form. However, pressing "Go" on the iOS keyboard is an implicit
+            submission and does not trigger a blur event.
+
 2015-08-03  Chris Dumez  <cdumez@apple.com>
 
         Fix error handling case in Cache::dumpContentsToFile()
index aa20dc4c7d874480799aa7604d0a1e855a193467..9fca4762a67499962da978c7b8a557137df200b1 100644 (file)
@@ -2437,6 +2437,9 @@ void WebPage::didReceivePolicyDecision(uint64_t frameID, uint64_t listenerID, ui
 void WebPage::didStartPageTransition()
 {
     m_drawingArea->setLayerTreeStateIsFrozen(true);
+#if PLATFORM(IOS)
+    m_hasFocusedDueToUserInteraction = false;
+#endif
 }
 
 void WebPage::didCompletePageTransition()