What to do about touch specific issues.

[flackr]

In our first meeting #3, we discussed ideas such as creating a separate sheet and reducing the priority of touch specific issues. I don't think this is a good idea, as many of these touch issues prominently affect developers on mobile websites. E.g. correct handling of touch-action, when touch should scroll, generate synthetic clicks, legacy mouse events, etc are critical to the correct operation of mobile sites.

As such, I suggest we have a column in the sheet to denote the need for touch support. We should currently have full test support for these on Chrome and Firefox where touch events can be generated in the desktop browsers, and can hopefully use this list as a signal for the need for some safari testing configuration with touch support.

[gsnedders]

The big thing is lack of coverage of touch support on wpt.fyi (Firefox seems to have it disabled, which IIRC is the default config on Linux; Safari on macOS doesn't have it; WebKitGTK doesn't support touch actions over WebDriver, and doesn't entirely have the same implementation as Safari anyway), right?

Clearly if we want automated results for anything we put into Interop 2023, then that's a significant concern. However, merely documenting that there are significant issues there (and what they are) still seems like a worthwhile goal (and perhaps to provide impetus to do something about the above).

I think as someone (@flackr?) said in the meeting, merely having checkbox columns in the main sheet for the input types affected is probably useful.

[gsnedders]

Firefox seems to have it disabled, which IIRC is the default config on Linux

Ah, no, I was mistaken: Marionette/GeckoDriver just doesn't support non-mouse events.

[karlcow]

Ah, no, I was mistaken: Marionette/GeckoDriver just doesn't support non-mouse events.

see mozilla/geckodriver#1760

[karlcow]

For touch, @jgraham is actively working on it for gecko driver.

[gsnedders]

see also: w3c/webdriver#1665