#475: isInputPending

Visit on Github.

Opened Feb 18, 2020

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.

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

Discussions

Comment by @dbaron Feb 19, 2020 (See Github)

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

Discussed Apr 13, 2020 (See Github)

David: This is marked as untriaged, which seems like an error on our end. There is a run-to-completion violation, which may or may not be a significant issue.

Peter: There can be cases where it makes sense to violate. Is there already a navigator.scheduling interface or does that need to be created?

David: Doesn't exist in Gecko as of now

Sangwhan: Have minor comments, but not significant enough for minutes, will comment later

Peter: Any other feedback? One thing that is weird is that requires instantiation? The notion of "continuous events" sounds foreign, is this specific to this spec? Otherwise seems okay with me.

There is also a mention of isFramePending..

David: Did you have any comments on continuous events?

Peter: I was concerned that it was a spec-specific nomenclature, should probably be defined elsewher

Comment by @dbaron Apr 13, 2020 (See Github)

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?).)

Comment by @plinss Apr 13, 2020 (See Github)

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'.

Comment by @cynthia Apr 14, 2020 (See Github)

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.

Comment by @acomminos Apr 16, 2020 (See Github)

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.

Discussed Apr 27, 2020 (See Github)

David: People seem to be ok with the run-to-completion violation... need to look at the response in more detail. We may be able to close this at the plenary.

... Will mark as propose close.

Comment by @dbaron Apr 29, 2020 (See Github)

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.

Comment by @dbaron Apr 29, 2020 (See Github)

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.