Bug 146848 - Consider implementing UIEvent.sourceCapabilities
Summary: Consider implementing UIEvent.sourceCapabilities
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://wicg.github.io/InputDeviceCapa...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-10 12:31 PDT by Rick Byers
Modified: 2024-02-01 04:45 PST (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Byers 2015-07-10 12:31:48 PDT
Concrete proposal here: https://github.com/RByers/InputDevice

We're close to doing an intent-to-ship for this in blink, so it would be great to get a better understanding of whether WebKit has any interest in this API or has any outstanding concerns before we ship it.
Comment 1 Sam Weinig 2015-07-10 17:59:48 PDT
Seams reasonable. What working group is this work slated for?
Comment 2 Rick Byers 2015-07-10 20:00:09 PDT
Thanks!  I've been talking with WebApps (on www-dom), one of the UI Events spec editors have expressed support (https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0117.html).  UI Events certainly seems like the right place.  But I haven't yet been able to get any further than that yet.  I suspect we won't block shipping on the politics here (but would, of course, block if there are unresolved technical concerns with the API).
Comment 3 Alexey Proskuryakov 2015-07-10 23:10:09 PDT
Thank you for filing the bug!

The spec appears to be mostly about touch/mouse events at this time, and it is also quite extensible for other event types. Do you have future extension directions in mind?

There is already a note alluding to complexities with keyboard events, and it seems likely that the complexities will grow as use cases and various virtual input devices are considered.
Comment 4 Rick Byers 2015-07-11 03:32:24 PDT
Yes, there has been some brainstorming in the community about how we might want to extend this over time.  Some ideas here: https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#.  But as you say, the details can get complex, so I figure it's best to iterate incrementally in a careful scenario-driven fashion rather than go nuts all at once.

My focus right now is to solve one particular long standing problem for devices with both a mouse and touchscreen (so not itself that interesting for WebKit).  But no one wants to make one-off hacks just for that, so we're trying to establish a reasonable device info pattern for the future.
Comment 5 Lucas Forschler 2019-02-06 09:18:23 PST
Mass move bugs into the DOM component.
Comment 6 Ben Frain 2020-02-26 02:26:14 PST
Any movement on this. 

Here's a use case: building a piece of UI. If it's a touch capable pointer, I want to expose some custom UI for text input. If it's a fine pointer I expose a standard input.

In Chrome I can use tabindex to capture focus on a wrapping element and then query that focus event's 'sourceCapabilities' to see whether 'firesTouchEvents' is true. The fork my code appropriately.

Unable to do this for Safari.
Comment 7 Ahmad Saleem 2024-02-01 04:43:47 PST
I can't find any WPT tests and also any Mozilla Position for this API.

Although, if I look into UI_Event.idl file in Chromium / Blink source, I can find it.

Anything to do here?