|Summary:||Implement UIScriptController::toggleCapsLock() for iOS|
|Product:||WebKit||Reporter:||Daniel Bates <dbates>|
|Component:||Tools / Tests||Assignee:||Daniel Bates <dbates>|
|Severity:||Normal||CC:||aestes, ews, lforschler, pvollan, thorton, webkit-bug-importer, wenson_hsieh|
|Version:||WebKit Local Build|
|Hardware:||iPhone / iPad|
|Bug Depends on:||191967, 191972|
Description Daniel Bates 2018-11-17 14:36:25 PST
We should implement TestRunner::toggleCapsLock() for iOS so that we can write tests to ensure that interactions with the caps lock key work correctly. This may also let us run the test LayoutTests/fast/events/detect-caps-lock.html on iOS.
Comment 1 Daniel Bates 2018-11-26 11:08:00 PST
I propose that we first move testRunner.toggleCapsLock() to UIScriptController before fixing this bug. See bug #191972 for more details.
Comment 2 Daniel Bates 2018-11-26 11:29:42 PST
(In reply to Daniel Bates from comment #0) > This may also let us run the test LayoutTests/fast/events/detect-caps-lock.html on iOS. This tests depends on making a window key and resigning a key window. The latter concept does not exist on iOS. From my understanding the closest equivalent is to make the app inactive, say by backgrounding the app. It may also be sufficient to switch to the app switcher. We may be able to mock this by adding more logic to Internals::applicationWillBecomeInactive(). Regardless more test infrastructure is needed. See bug #191973 for more details.
Comment 3 Daniel Bates 2018-11-26 11:33:57 PST
Created attachment 355659 [details] Patch Patch will not apply to trunk. It depends on the patch for bug #191967 and the patch for bug #191972.
Comment 4 Daniel Bates 2018-11-26 14:43:42 PST
Created attachment 355676 [details] Patch Patch will not apply to trunk. It depends on the patch for bug #191967.
Comment 5 Daniel Bates 2018-11-26 15:01:31 PST
Created attachment 355682 [details] Patch for EWS No change. Rebased patch now that the patch for bug #191967 landed so that the patch can apply to trunk!
Comment 6 Build Bot 2018-11-26 21:02:03 PST
Comment on attachment 355682 [details] Patch for EWS Attachment 355682 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10161775 New failing tests: fast/repaint/placeholder-after-caps-lock-hidden.html fast/forms/password-scrolled-after-caps-lock-toggled.html
Comment 7 Build Bot 2018-11-26 21:02:08 PST
Created attachment 355710 [details] Archive of layout-test-results from ews125 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews125 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Comment 8 Daniel Bates 2018-12-17 11:11:05 PST
Comment on attachment 355682 [details] Patch for EWS View in context: https://bugs.webkit.org/attachment.cgi?id=355682&action=review > LayoutTests/platform/ios-wk2/TestExpectations:60 > +fast/forms/auto-fill-button/caps-lock-indicator-should-be-visible-when-after-hiding-auto-fill-strong-password-button.html [ Pass ] > +fast/forms/auto-fill-button/caps-lock-indicator-should-not-be-visible-when-auto-fill-strong-password-button-is-visible.html [ Pass ] > +fast/forms/password-scrolled-after-caps-lock-toggled.html [ Pass ] > +fast/repaint/placeholder-after-caps-lock-hidden.html [ Pass ] Actually, all of these tests are expected to fail with the public iOS SDK as they depend on the UIKit fix for <rdar://problem/45208902> that has not shipped. The reason EWS didn't consider fast/forms/auto-fill-button/caps-lock-indicator-should-be-visible-when-after-hiding-auto-fill-strong-password-button.html as a failure is because this file does not exist. I am unclear why fast/forms/auto-fill-button/caps-lock-indicator-should-not-be-visible-when-auto-fill-strong-password-button-is-visible.html didn't fail on EWS. It should as it depends on the fix for <rdar://problem/45208902>.
Comment 9 Daniel Bates 2018-12-17 11:19:38 PST
Committed r239277: <https://trac.webkit.org/changeset/239277>