isInputPending

[acomminos]

Hello TAG!

I'm requesting a TAG review of isInputPending. There was some prior discussion here, however it appears to have pivoted to discuss the postTask family of APIs.

In a nutshell, isInputPending is an API for developers to provide more intelligent cooperative multitasking by allowing developers to yield efficiently when there is pending user input to be handled.

• Explainer: https://github.com/WICG/is-input-pending
• Specification URL: https://wicg.github.io/is-input-pending
• Security and Privacy self-review: https://github.com/WICG/is-input-pending/blob/master/PRIVACY_AND_SECURITY.md
• Primary contacts:
  • Andrew Comminos (@acomminos), Facebook
  • Nate Schloss (@n8schloss), Facebook
  • Nicolás Peña Moreno (@npm1), Google
  • Tim Dresser (@tdresser), Google
• Organization(s)/project(s) driving the specification: Facebook, Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • WebPerfWG at TPAC 2019
  • WebPerfWG biweekly calls (part 1, part 2, part 3)
  • TAG review for scheduling APIs
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://www.chromestatus.com/feature/5719830432841728

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is being done: WICG
• This work is being funded by: Facebook, Google

You should also know that...

• We ran a Chrome origin trial for the API from M74 to M78.
  • Positive results, reduced event scheduling latency without impacting page load times (see TPAC discussion)
• The isInputPending spec requires that any event that is detectable using isInputPending must remain fixed to the origin of the agent that invoked isInputPending (e.g. the UA must not dispatch an event to an agent of a different origin). Implementors must take special care to avoid event leakage in the event of frame movement or focus changes (see explainer).

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @acomminos, @n8schloss

[dbaron]

Also worth noting that #415 has some discussion that's probably relevant to isInputPending.

[dbaron]

We just looked at this in the TAG's breakout B today.

One thing we're curious about is what else is on navigator.scheduling (since it looks new to us) and whether that's the right place for this API (and isFramePending, #415).

@plinss is also a little concerned about describing a new category of events off in this corner of the world of web specs (rather than, say, DOM). (I also find that part of the spec a bit confusing; it's not clear to me what ContinuousEvent is (is it a name developers can type that means something?).)

[plinss]

Also the note in the spec about requiring the options to be instantiated once is a bit weird. I understand the performance impact, but maybe that should be a suggestion for authors rather than a 'requirement'.

[cynthia]

There are some input-but-not-quite case events (e.g. GamepadEvent - https://w3c.github.io/gamepad/#gamepadevent-interface) that feel like it could benefit from this, although it does seem to be very focused on standard input for webapps.

[acomminos]

Thank you for the feedback!

One thing we're curious about is what else is on navigator.scheduling (since it looks new to us) and whether that's the right place for this API (and isFramePending, #415).

One of the concerns raised in the Web Perf WG was cluttering namespaces with these scheduling APIs, so we put them behind the navigator.scheduling interface to mitigate this. We're definitely open to other suggestions here.

[...] a little concerned about describing a new category of events off in this corner of the world of web specs (rather than, say, DOM)

We weren't aware of any other specs that could benefit from reusing this definition, and figured that having a lightweight standalone definition would be acceptable. The closest analogue that I'm aware of is pointer events' definition of events which may have a coalesced events list (but we wanted a superset of this).

[...] it's not clear to me what ContinuousEvent is (is it a name developers can type that means something?).)

No, it's just a definition of a class of events. I'll make this clearer, as this is not intended to be web-exposed.

Also the note in the spec about requiring the options to be instantiated once is a bit weird. I understand the performance impact, but maybe that should be a suggestion for authors rather than a 'requirement'.

Sounds good to me. I'll drop this requirement and replace it with a default options struct, with some additional implementer guidance.

There are some input-but-not-quite case events (e.g. GamepadEvent - https://w3c.github.io/gamepad/#gamepadevent-interface) that feel like it could benefit from this, although it does seem to be very focused on standard input for webapps.

I'm not quite sure use of isInputPending would align with the intended use of GamepadEvent (as it's intended to be polled during a rAF), though I'm sure other continuous-like event types may eventually want to be queryable by isInputPending.

[dbaron]

No, it's just a definition of a class of events. I'll make this clearer, as this is not intended to be web-exposed.

Thanks. The current draft is a lot clearer.

[dbaron]

The TAG discussed this briefly at our plenary meeting today, and we're happy with closing this. We've been glad to see your responses to the comments we had. Thanks for requesting review from the TAG.

We hope you'll continue to get appropriate feedback and advance this proposal through the appropriate standards process.