<rdar://problem/32542437>
...and I might as well fix <rdar://problem/32542433> too while I'm at it.
Created attachment 346610 [details] Patch
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)
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.
(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.
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...
Created attachment 346626 [details] Patch for landing
Comment on attachment 346626 [details] Patch for landing Clearing flags on attachment: 346626 Committed r234601: <https://trac.webkit.org/changeset/234601>
(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
(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...
(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?
(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.
(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.