https://bugs.webkit.org/show_bug.cgi?id=214688
<rdar://problem/65993683>
Reviewed by Darin Adler.
Source/WebCore/PAL:
Remove logging added in r264882, r264890, r264892, and r264896.
* pal/spi/ios/GraphicsServicesSPI.h:
Source/WebKit:
Remove logging added in r264882, r264890, r264892, and r264896.
* Platform/spi/ios/UIKitSPI.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _singleTapIdentified:]):
(-[WKContentView _singleTapRecognized:]):
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::commitPotentialTap):
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::handleSyntheticClick):
Tools:
Attempt another speculative fix for this flaky test, motivated by logging introduced in r264896. This recently
introduced telemetry would suggest that this test fails when the act of handling a synthetic modifier keydown
fails to update `GSKeyboardRef`'s live modifier flags if the keyboard layout changes mid-event, forcing the
existing `GSKeyboardRef` to be destroyed and rebuilt.
In this case, the keyboard layout changes from "Hebrew" to "US" when this test fails. There is only one (sane)
explanation for this, which is that one of the `editing/input/ios/rtl-keyboard-input-*.html` tests switch to an
RTL keyboard ("he_IL" in both cases) by swizzling out `-currentInputMode` and `-currentInputModeInPreference` on
`UIKeyboardInputModeController`. While the swizzling is torn down in between test runs via logic in
`TestController::platformResetStateToConsistentValues`, it's possible that this change hasn't propagated to
the UIKit or GraphicsServices layers -- in other words, `UIApplication`'s `GSKeyboardRef` remains stuck in the
Hebrew layout until the next time `-GSKeyboardForHWLayout:forceRebuild:createIfNeeded:` forces the keyboard to
be rebuilt, which (in this case) seems to happen while running `shift-click-includes-existing-selection.html`.
For reasons that are still unclear, this lazy regeneration of the `GSKeyboardRef` causes GraphicsServices' live
modifier state to not update when handling a shift key down HID event. However, we might be able to fix this by
forcing UIKit to sync the default (unswizzled) keyboard layout back to its `GSKeyboardRef` immediately when we
stop swizzling `UIKeyboardInputModeController` after running a test that attempts to simulate changing keyboard
input modes.
* WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
Call `-prepareKeyboardInputModeFromPreferences:` to force the UIApp to update its hardware keyboard state (i.e.
`GSKeyboardRef`).
* WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::singleTapAtPointWithModifiers):
Also, restore this method to how it was prior to r264890, as it doesn't seem like waiting for the HID marker
event after synthesizing a keydown had any effect.
* WebKitTestRunner/ios/mainIOS.mm:
(-[WebKitTestRunnerApp handleKeyHIDEvent:]): Deleted.
WebKitLibraries:
Remove logging added in r264882, r264890, r264892, and r264896.
* WebKitPrivateFrameworkStubs/appletvos/13/GraphicsServices.framework/GraphicsServices.tbd:
* WebKitPrivateFrameworkStubs/appletvos/14/GraphicsServices.framework/GraphicsServices.tbd:
* WebKitPrivateFrameworkStubs/iOS/13/GraphicsServices.framework/GraphicsServices.tbd:
* WebKitPrivateFrameworkStubs/iOS/14/GraphicsServices.framework/GraphicsServices.tbd:
* WebKitPrivateFrameworkStubs/watchos/6/GraphicsServices.framework/GraphicsServices.tbd:
* WebKitPrivateFrameworkStubs/watchos/7/GraphicsServices.framework/GraphicsServices.tbd:
LayoutTests:
Remove the failing test expectation.
* platform/ios-simulator-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/227630@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@264907 268f45cc-cd09-0410-ab3c-d52691b4dbfc
d0ceff02ad