Intent to Experiment: navigator.scheduling.isInputPending
acom...@fb.com
Contact emails
acom...@fb.com, n...@fb.com, tdre...@google.com, pani...@google.com
Explainer
https://github.com/WICG/is-input-pending/
Summary
A method to query whether or not input events of a given type are likely to be dispatched to a document. Intended for use in JS schedulers to improve the responsiveness of pages by yielding when input is pending prior to processing lower priority tasks.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLq8t56CbaQ/KdbOY7ZHCwAJ
Goals for experimentation
We’d like to measure the reduction in event dispatch latency in scheduler-driven pages as a result of yielding more intelligently using this API. Our working hypothesis is that pending input events will be handled sooner due to the scheduler’s improved ability to cooperatively multitask, improving page responsiveness. In particular, Facebook intends on measuring the time elapsed between an event’s timestamp and the time the event handler was dispatched for this.
We’d also like to know what sort of input events developers are interested in querying for specifically, to determine the level of granularity that should be exposed by this API.
Experimental timeline
M74 - M76.
Any risks when the experiment finishes?
The correctness of intended consumers of the feature (JS schedulers) should be unaffected by the removal of the API. It’s worth noting that some schedulers could potentially bias their scheduling design towards a functional implementation of isInputPending, which could negatively affect the responsiveness of scheduling without this API present.
Ongoing technical constraints
None.
Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
No, only Windows, Mac, Linux, and Chrome OS. The current implementation requires site-per-process to perform attribution of pending input events, which is not shipped by default on Android. This will be addressed before any intent to ship.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5719830432841728
smaug
> Contact emails
>
> acom...@fb.com <mailto:acom...@fb.com>, n...@fb.com <mailto:n...@fb.com>, tdre...@google.com <mailto:tdre...@google.com>, pani...@google.com
> <mailto:pani...@google.com>
>
> Explainer
>
> https://github.com/WICG/is-input-pending/
>
>
> Summary
>
> A method to query whether or not input events of a given type are likely to be dispatched to a document. Intended for use in JS schedulers to improve
> the responsiveness of pages by yielding when input is pending prior to processing lower priority tasks.
>
Especially privacy and security part is rather unclear. If there are for example keyboard events _pending_, one can't
know the target beforehand, since the caller of this new API may move focus elsewhere.
-Olli
>
> Link to “Intent to Implement” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eLq8t56CbaQ/KdbOY7ZHCwAJ
>
>
> Goals for experimentation
>
> We’d like to measure the reduction in event dispatch latency in scheduler-driven pages as a result of yielding more intelligently using this API. Our
> working hypothesis is that pending input events will be handled sooner due to the scheduler’s improved ability to cooperatively multitask, improving
> page responsiveness. In particular, Facebook intends on measuring the time elapsed between an event’s timestamp and the time the event handler was
> dispatched for this.
>
>
> We’d also like to know what sort of input events developers are interested in querying for specifically, to determine the level of granularity that
> should be exposed by this API.
>
>
> Experimental timeline
>
> M74 - M76.
>
>
> Any risks when the experiment finishes?
>
> The correctness of intended consumers of the feature (JS schedulers) should be unaffected by the removal of the API. It’s worth noting that some
> schedulers could potentially bias their scheduling design towards a functional implementation of isInputPending, which could negatively affect the
> responsiveness of scheduling without this API present.
>
>
> Ongoing technical constraints
>
> None.
>
>
> Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> No, only Windows, Mac, Linux, and Chrome OS. The current implementation requires site-per-process to perform attribution of pending input events,
> which is not shipped by default on Android. This will be addressed before any intent to ship.
>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca0587cc-b9c3-4323-b013-f3add6319457%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca0587cc-b9c3-4323-b013-f3add6319457%40chromium.org?utm_medium=email&utm_source=footer>.
acom...@fb.com
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/82ff0549-5fb0-419f-b856-55f17ac94851%40chromium.org.