Title: [198810] trunk/Source/WebKit2
Revision
198810
Author
enr...@apple.com
Date
2016-03-29 16:34:54 -0700 (Tue, 29 Mar 2016)

Log Message

When moving focus from one select element to another (iPhone) the value is committed to the newly focused element.
https://bugs.webkit.org/show_bug.cgi?id=155958
rdar://problem/22738524

Reviewed by Tim Horton.

We should not delay the call to endEditing until we receive
stopAssistingNode, because by then the assisted node might have already
changed. We need to call endEditing to commit potential changes every
time we tap. This way we can make sure the editing session on the select
element has been completed. This affects only single select elements on
iPhone, where the change to the actual DOM element is delayed until we
stop interacting with the element. On iPad or for multi-select elements,
the change to the DOM happens immediately.

* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _singleTapCommited:]):
(-[WKContentView _attemptClickAtLocation:]):
(-[WKContentView _stopAssistingNode]):

Modified Paths

Diff

Modified: trunk/Source/WebKit2/ChangeLog (198809 => 198810)


--- trunk/Source/WebKit2/ChangeLog	2016-03-29 23:19:11 UTC (rev 198809)
+++ trunk/Source/WebKit2/ChangeLog	2016-03-29 23:34:54 UTC (rev 198810)
@@ -1,3 +1,25 @@
+2016-03-28  Enrica Casucci  <enr...@apple.com>
+
+        When moving focus from one select element to another (iPhone) the value is committed to the newly focused element.
+        https://bugs.webkit.org/show_bug.cgi?id=155958
+        rdar://problem/22738524
+
+        Reviewed by Tim Horton.
+
+        We should not delay the call to endEditing until we receive
+        stopAssistingNode, because by then the assisted node might have already
+        changed. We need to call endEditing to commit potential changes every
+        time we tap. This way we can make sure the editing session on the select
+        element has been completed. This affects only single select elements on
+        iPhone, where the change to the actual DOM element is delayed until we
+        stop interacting with the element. On iPad or for multi-select elements,
+        the change to the DOM happens immediately.
+
+        * UIProcess/ios/WKContentViewInteraction.mm:
+        (-[WKContentView _singleTapCommited:]):
+        (-[WKContentView _attemptClickAtLocation:]):
+        (-[WKContentView _stopAssistingNode]):
+
 2016-03-29  Brian Burg  <bb...@apple.com>
 
         Unreviewed build fix after r198793.

Modified: trunk/Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm (198809 => 198810)


--- trunk/Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm	2016-03-29 23:19:11 UTC (rev 198809)
+++ trunk/Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm	2016-03-29 23:34:54 UTC (rev 198810)
@@ -1448,6 +1448,7 @@
         _hasTapHighlightForPotentialTap = NO;
     }
 
+    [_inputPeripheral endEditing];
     _page->commitPotentialTap();
 
     if (!_isExpectingFastSingleTapCommit)
@@ -1486,6 +1487,7 @@
     if (![self isFirstResponder])
         [self becomeFirstResponder];
 
+    [_inputPeripheral endEditing];
     _page->handleTap(location);
 }
 
@@ -3587,7 +3589,6 @@
     _formInputSession = nil;
     _isEditable = NO;
     _assistedNodeInformation.elementType = InputType::None;
-    [_inputPeripheral endEditing];
     _inputPeripheral = nil;
 
     [self _stopAssistingKeyboard];
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to