Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pointer action subtype behaviour when subtype is unsupported #1665

Open
gsnedders opened this issue Jun 10, 2022 · 4 comments
Open

Pointer action subtype behaviour when subtype is unsupported #1665

gsnedders opened this issue Jun 10, 2022 · 4 comments

Comments

@gsnedders
Copy link
Contributor

e.g., what happens when you send a touch action when the browser and/or device doesn't support it?

It's unclear whether Create a pointer input source is actually meant to be fallible (i.e., if the subtype is unsupported), nor and process pointer parameters merely checks if the subtype is one the spec defines.

Seemly the behaviour currently is Marionette/GeckoDriver gives "invalid argument" (https://searchfox.org/mozilla-central/rev/973000acec0cbf7211e0fad89ca00c352aeb8384/remote/marionette/action.js#132), WebKit does a bunch of aliasing (https:/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp#L2115), and ChromeDriver I think supports everything everywhere.

@patrickangle
Copy link

WebKit currently does alias the "mouse" subtype to "touch" on iOS, and "touch" to "mouse" on macOS. While we could probably get rid of the aliasing on macOS without issue, I know internally teams have tests using pointer events with "mouse" subtype against iOS, and we suspect this holds true externally as well, making the removal of that particular aliasing a non-starter for us from a compatibility point of view.

@gsnedders
Copy link
Contributor Author

Selenium/Java defaults to mouse events, which is probably indicative of general expectations that mouse events are the default are always possible:

https:/SeleniumHQ/selenium/blob/4f09bf0c744cb8188ddf8328e7a5daf2f0903898/java/src/org/openqa/selenium/interactions/Actions.java#L502-L507

In a sense, this follows the general web platform pattern of supporting mouse events for compatibility, even when the input is not a mouse. (e.g., see how every mobile browser fires mousedown, etc.)

@css-meeting-bot
Copy link
Member

The Browser Testing and Tools Working Group just discussed Pointer action subtype behaviour when subtype is unsupported.

The full IRC log of that discussion <AutomatedTester> topic: Pointer action subtype behaviour when subtype is unsupported
<AutomatedTester> github: https://issues/1665
<AutomatedTester> patrickangle: currently it is not clear in webdriver classic how we are supposed to handle "unsupported" on a platform. e.g. Touch on MacOS won't work
<jgraham1> q+
<AutomatedTester> ... our current proposal is mouse is the default and it is aliased to the relevant item like pointer, mouse, touch
<AutomatedTester> ack next
<AutomatedTester> jgraham: I think that makes sense. It is a bug
<AutomatedTester> ... the spec can add new types in the future, we've done it before, so it make sense to tell you that the type is not supported
<AutomatedTester> ... in gecko we inject "fake events" that isTrusted
<AutomatedTester> ... but not at DOM level
<AutomatedTester> ... [explains how it works on Firefox for android]
<AutomatedTester> ... and in principle I am happy with that idea
<sadym> q+
<AutomatedTester> ack next
<AutomatedTester> gsnedders: There is more info in the issue tracker
<AutomatedTester> ... like on MacOS we can do it
<AutomatedTester> ... [describes complext touch inputs that can't be down with a mouse]
<AutomatedTester> sadym: is it only about the subtype? or is about touch and click in a test?
<AutomatedTester> patrickangle: we're mostly talking about the subtype here
<AutomatedTester> ... and what to do when one is not supported?
<jgraham1> q+
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> jgraham: Supporting touch on desktop is kinda allowed
<AutomatedTester> ... we can update the language in the spec but it is a bit of a question on what to do with your users
<AutomatedTester> ... if things still work great
<AutomatedTester> gsnedders: the pointer tests in wpt they want to test everything separately
<AutomatedTester> ... so knowing if something is aliased is useful
<AutomatedTester> ... and if fallible that can be useful
<AutomatedTester> ... but sometimes the aliasing can make testing pointers harder
<AutomatedTester> jgraham: the spec is wooly here... and it works pretty well for most cases
<AutomatedTester> ... I don't think that this potentially needs to be in a metric
<AutomatedTester> gsnedders: There is talk around getting the mobile cases into the Interop report
<AutomatedTester> gsnedders: for the normal users it defaulting to the alias of what the pointer is doing is "good enough"
<AutomatedTester> ... but isn't great for wpt

@gsnedders
Copy link
Contributor Author

Also: as mentioned in the meeting, things like web-platform-tests/wpt#31782 show there is some use for knowing ahead-of-time whether a subtype is supported—and perhaps also whether it is aliased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants