Bug 188335 – [iOS] Tests that try to interact with the QuickType bar time out on iOS 11+

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Wenson Hsieh]

<rdar://problem/32542437>

[Wenson Hsieh]

...and I might as well fix <rdar://problem/32542433> too while I'm at it.

[Wenson Hsieh]

Created attachment 346610 [details]
Patch

[Tim Horton]

Comment on attachment 346610 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346610&action=review

> LayoutTests/ChangeLog:27
> +        Add a new UIHelper method to type a character using the keyboard. Sends hardware keyboard events on the WebKit2
> +        port of iOS, and uses EventSender elsewhere.

Should we just make EventSender work so the tests don't have to mind? Does that even make sense? (like, is it possible to hide this behind the existing interface)

[Wenson Hsieh]

Comment on attachment 346610 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346610&action=review

>> LayoutTests/ChangeLog:27
>> +        port of iOS, and uses EventSender elsewhere.
> 
> Should we just make EventSender work so the tests don't have to mind? Does that even make sense? (like, is it possible to hide this behind the existing interface)

IIRC, this was my original approach back in 2015, when I prototyped gesture/interaction testing in WK2 iOS. We ultimately went with UIScriptController instead, which offers more flexibility and doesn't limit us to dispatching and waiting for all events to finish synchronously, since its API is all completion-block-based.

In a sense, UIHelper and its static functions help mitigate this schism in testing API by providing ways to simulate cross-platform user interaction, but I think that in the future, we would ideally implement the UIScriptController stubs on macOS so that interactions could be simulated via UIScriptController, and then EventSenderProxy could then be implemented in terms of calls to UIScriptController.

[Tim Horton]

(In reply to Wenson Hsieh from comment #4)
> Comment on attachment 346610 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=346610&action=review
> 
> >> LayoutTests/ChangeLog:27
> >> +        port of iOS, and uses EventSender elsewhere.
> > 
> > Should we just make EventSender work so the tests don't have to mind? Does that even make sense? (like, is it possible to hide this behind the existing interface)
> 
> IIRC, this was my original approach back in 2015, when I prototyped
> gesture/interaction testing in WK2 iOS. We ultimately went with
> UIScriptController instead, which offers more flexibility and doesn't limit
> us to dispatching and waiting for all events to finish synchronously, since
> its API is all completion-block-based.

> In a sense, UIHelper and its static functions help mitigate this schism in

Good point.

> testing API by providing ways to simulate cross-platform user interaction,
> but I think that in the future, we would ideally implement the
> UIScriptController stubs on macOS so that interactions could be simulated
> via UIScriptController, and then EventSenderProxy could then be implemented
> in terms of calls to UIScriptController.

Ah! That sounds like a good plan for maximum flexibility.

[Wenson Hsieh]

Comment on attachment 346610 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=346610&action=review

> Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:-393
> -    id UIKeyboardPredictionViewClass = NSClassFromString(@"UIKeyboardPredictionView");

Ah, this means I can also remove the UIKeyboardPredictionView forward declaration in UIKitTestSPI.h...

[Wenson Hsieh]

Created attachment 346626 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 346626 [details]
Patch for landing

Clearing flags on attachment: 346626

Committed r234601: <https://trac.webkit.org/changeset/234601>

[Ryan Haddad]

(In reply to WebKit Commit Bot from comment #8)
> Committed r234601: <https://trac.webkit.org/changeset/234601>

The following API test is timing out on iOS Simulator after this change:

    TestWebKitAPI.KeyboardInputTests.CaretSelectionRectAfterRestoringFirstResponder
        2018-08-06 09:28:39.260 TestWebKitAPI[9284:303241744] Expected a caret rect of {{16, 13}, {3, 15}}, but still observed {{16.000000000000004, 13.000000000000002}, {2.0631577968597412, 15.000000000000002}}

https://build.webkit.org/builders/Apple%20iOS%2011%20Simulator%20Release%20WK2%20%28Tests%29/builds/6630

[Wenson Hsieh]

(In reply to Ryan Haddad from comment #9)
> (In reply to WebKit Commit Bot from comment #8)
> > Committed r234601: <https://trac.webkit.org/changeset/234601>
> 
> The following API test is timing out on iOS Simulator after this change:
> 
>    
> TestWebKitAPI.KeyboardInputTests.
> CaretSelectionRectAfterRestoringFirstResponder
>         2018-08-06 09:28:39.260 TestWebKitAPI[9284:303241744] Expected a
> caret rect of {{16, 13}, {3, 15}}, but still observed {{16.000000000000004,
> 13.000000000000002}, {2.0631577968597412, 15.000000000000002}}
> 
> https://build.webkit.org/builders/
> Apple%20iOS%2011%20Simulator%20Release%20WK2%20%28Tests%29/builds/6630

Taking a look now. Looks like it just needs to be tweaked a bit...

[Wenson Hsieh]

(In reply to Ryan Haddad from comment #9)
> (In reply to WebKit Commit Bot from comment #8)
> > Committed r234601: <https://trac.webkit.org/changeset/234601>
> 
> The following API test is timing out on iOS Simulator after this change:
> 
>    
> TestWebKitAPI.KeyboardInputTests.
> CaretSelectionRectAfterRestoringFirstResponder
>         2018-08-06 09:28:39.260 TestWebKitAPI[9284:303241744] Expected a
> caret rect of {{16, 13}, {3, 15}}, but still observed {{16.000000000000004,
> 13.000000000000002}, {2.0631577968597412, 15.000000000000002}}
> 
> https://build.webkit.org/builders/
> Apple%20iOS%2011%20Simulator%20Release%20WK2%20%28Tests%29/builds/6630

Also, surely you mean after https://trac.webkit.org/changeset/234600/webkit, no?

[Ryan Haddad]

(In reply to Wenson Hsieh from comment #11)
> (In reply to Ryan Haddad from comment #9)
> Also, surely you mean after https://trac.webkit.org/changeset/234600/webkit,
> no?
Indeed, my apologies.

[Wenson Hsieh]

(In reply to Ryan Haddad from comment #12)
> (In reply to Wenson Hsieh from comment #11)
> > (In reply to Ryan Haddad from comment #9)
> > Also, surely you mean after https://trac.webkit.org/changeset/234600/webkit,
> > no?
> Indeed, my apologies.

No worries :)

Migrated the CC's over to that bug.