Currently we are using the macOS ones but we should use the iOS ones.
<rdar://problem/47460637>
Created attachment 367211 [details] Patch
Comment on attachment 367211 [details] Patch Attachment 367211 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/11839482 New failing tests: media/modern-media-controls/media-controller/ios/media-controller-ios-do-not-hide-controls-when-tapping-button.html media/video-fullscreen-reload-crash.html media/modern-media-controls/media-controller/ios/media-controller-ios-layout-traits-modern-compatibility-mode.html
Created attachment 367212 [details] Archive of layout-test-results from ews123 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
I don't understand the failures as reported by EWS, and installing a configuration similar to the bot that reported the failure doesn't reproduce. I'm going to land this as-is and take a look at the other bots.
Committed r244253: <https://trac.webkit.org/changeset/244253>
Committed r244259: <https://trac.webkit.org/changeset/244259>
I landed a speculative fix for the bot failures. I think the reason was that we used to have a platform-based check and this patch switched to one based on feature-discovery. Prior to this patch, we'd use the macOS layout traits if navigator.platform === "MacIntel" and the iOS traits otherwise. With this patch, we use the iOS layout traits if touch events are supported and macOS otherwise. I think this led the open-source iOS bots to using the macOS layout traits since touch events aren't support, or at least not advertised using `createTouch in document`. So my speculative fix is to use iOS if either we support touches or navigator.platform !== "MacIntel". Hopefully this will address the bot issues.
The speculative fix looks solid, bots look happy.