Changeset 195602 in webkit

Timestamp:

Jan 26, 2016 11:12:37 AM (8 years ago)

Author:

timothy_horton@apple.com

Message:

REGRESSION (r194557): Keyboard shortcuts stop working after the WKWebView is unparented and reparented
​https://bugs.webkit.org/show_bug.cgi?id=153492
<rdar://problem/24138989>

Reviewed by Dan Bernstein.

• UIProcess/ios/WKContentViewInteraction.h:
• UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView canBecomeFirstResponder]):
(-[WKContentView becomeFirstResponder]):
(-[WKContentView resignFirstResponder]):
When WKWebView is unparented, WKContentView will attempt to resignFirstResponder upwards,
first asking WKWebView. After r194557, WKWebView will accept first responder and forward
it on to the WKContentView, which will happily accept it again, despite being the view
that's trying to resign. This will cause us to completely lose first responder,
where it was actually supposed to propagate up above WKWebView to the client.

Keep track of when WKContentView is resigning first responder, and don't
let it become first responder while it is doing so, breaking the cycle.

Location:

trunk/Source/WebKit2

Files:

• ChangeLog (modified) (1 diff)
• UIProcess/ios/WKContentViewInteraction.h (modified) (1 diff)
• UIProcess/ios/WKContentViewInteraction.mm (modified) (4 diffs)

trunk/Source/WebKit2/ChangeLog

@@ +1 @@
+2016-01-26  Tim Horton  <timothy_horton@apple.com>
+
+        REGRESSION (r194557): Keyboard shortcuts stop working after the WKWebView is unparented and reparented
+        https://bugs.webkit.org/show_bug.cgi?id=153492
+        <rdar://problem/24138989>
+
+        Reviewed by Dan Bernstein.
+
+        * UIProcess/ios/WKContentViewInteraction.h:
+        * UIProcess/ios/WKContentViewInteraction.mm:
+        (-[WKContentView canBecomeFirstResponder]):
+        (-[WKContentView becomeFirstResponder]):
+        (-[WKContentView resignFirstResponder]):
+        When WKWebView is unparented, WKContentView will attempt to resignFirstResponder upwards,
+        first asking WKWebView. After r194557, WKWebView will accept first responder and forward
+        it on to the WKContentView, which will happily accept it again, despite being the view
+        that's trying to resign. This will cause us to completely lose first responder,
+        where it was actually supposed to propagate up above WKWebView to the client.
+
+        Keep track of when WKContentView is resigning first responder, and don't
+        let it become first responder while it is doing so, breaking the cycle.
+
 2016-01-25  Ada Chan  <adachan@apple.com>
 

trunk/Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h

@@ -162 +162 @@
     BOOL _isExpectingFastSingleTapCommit;
     BOOL _showDebugTapHighlightsForFastClicking;
+
+    BOOL _isResigningFirstResponder;
 }
 

trunk/Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm

@@ -670 +670 @@
 - (BOOL)canBecomeFirstResponder
 {
+    if (_isResigningFirstResponder)
+        return NO;
     // We might want to return something else
     // if we decide to enable/disable interaction programmatically.
@@ -677 +679 @@
 - (BOOL)becomeFirstResponder
 {
+    if (_isResigningFirstResponder)
+        return NO;
     BOOL didBecomeFirstResponder = [super becomeFirstResponder];
     if (didBecomeFirstResponder)
@@ -688 +692 @@
     // FIXME: Maybe we should call resignFirstResponder on the superclass
     // and do nothing if the return value is NO.
+
+    _isResigningFirstResponder = YES;
 
     if (!_webView->_activeFocusedStateRetainCount) {
@@ -699 +705 @@
     [_textSelectionAssistant deactivateSelection];
 
-    return [super resignFirstResponder];
+    bool superDidResign = [super resignFirstResponder];
+
+    _isResigningFirstResponder = NO;
+
+    return superDidResign;
 }