Bug 191815

Summary: Implement UIScriptController::toggleCapsLock() for iOS
Product: WebKit Reporter: Daniel Bates <dbates>
Component: Tools / TestsAssignee: Daniel Bates <dbates>
Status: RESOLVED FIXED    
Severity: Normal CC: aestes, ews, lforschler, pvollan, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: iPhone / iPad   
OS: iOS 12   
Bug Depends on: 191967, 191972    
Bug Blocks: 190571    
Attachments:
Description Flags
Patch
none
Patch
none
Patch for EWS
aestes: review+, ews: commit-queue-
Archive of layout-test-results from ews125 for ios-simulator-wk2 none

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>
Comment 10 Radar WebKit Bug Importer 2018-12-17 11:20:40 PST
<rdar://problem/46783768>