isInputPending

The Problem

Today, developers must tradeoff how fast they can accomplish large blocks of work and how responsive they are to user input. For example, during page load, there may be a set of components and scripts to initialize. These are often ordered by priority: for example, first installing event handlers on primary buttons, then a search box, then a messaging widget, and then finally moving on to analytics scripts and ads.

In this example, a developer can either optimize for:

• Completing all work as fast as possible.
  • For example, we want the messaging widget to be initialized by the time the user interacts with it.
• Responding to user input as fast as possible.
  • For example, when the user taps one of our primary buttons, we don't want to block until our whole page is ready to go before responding.

Completing all work as fast as possible is easy, the developer can simply execute all the work in the minimal number of tasks.

Responding to user input as fast as possible today requires paying some performance overhead, and minimizing that performance overhead is quite complicated. The most straight forward approach is to perform a unit of work, and then continue the work in a macrotask such as setTimeout(..., 0).

The performance overhead of this approach comes from a few sources:

• Inherent overhead in posting a task.
• Task throttling from the browser.
• Execution of other browser work, such as rendering, postponing task execution.
  • Sometimes this is desirable, to get something visible on screen sooner. If we're executing script which is required to display our app however, this isn't desirable.

Proposal

In order to enable developers to complete their work as fast as possible if the user isn't interacting, but respond to user input as fast as possible if input occurs, we propose adding a new navigator.scheduling.isInputPending() API. This API takes an IsInputPendingOptions dictionary, which may be configured to include discrete input (e.g. mouse clicks, key presses), or discrete and continuous input (e.g. mouse movement, touch dragging). If given no options object, the default is the former.

See the draft specification here.

Example

Using navigator.scheduling.isInputPending() requires having some way to schedule tasks. We anticipate most adoption coming from frameworks and large sites. However, if you have a list of tasks that need executing, adoption is very simple.

let taskQueue = [task1, task2, ...];

const options = {
  includeContinuous: false,
};

function doWork() {
  while (let task = taskQueue.pop()) {
    task.execute();
    if (navigator.scheduling.isInputPending(options)) {
      setTimeout(doWork, 0);
      break;
    }
  }
}

doWork();

What about requestIdleCallback?

requestIdleCallback has the capacity to solve similar problems, but only when the work being done is low priority. It waits for an idle period before executing the associated work. In the example of registering behavior for a variety of UI components, we can't wait for an idle period before continuing to register additional UI components.

We could use an API shape similar to requestIdleCallback, which instead posted a normal priority task, and provided a parallel to IdleDeadline.timeRemaining() which returned 0 if there was pending user input. However, this forces clients to use a specific method of posting a task, which is less flexible than the more generic scheduling.isInputPending() proposal.

How slow is posting a task, really?

Breaking tasks up into small chunks has some overhead, but is it really enough to warrant a new API?

The web is different from most platforms due to it's compositional nature. The overhead of posting a task isn't merely the scheduling overhead. Posting a task may involve being interrupted by arbitrary third party content on the page. For many pages, it isn't feasible to regularly yield to third party script in order to repond to input quickly.

Constraints

Ideally, a solution to this problem would meet the following constraints:

1. Enable stopping JS execution when input arrives.
2. Enable efficiently resuming JS execution once input has been processed.
3. Provide the browser a way to stop the JS from executing when input isn’t pending, in case the browser decides it really needs to draw something.
4. Not require paying the cost of posting a task unless the browser has pending high priority work
5. Prevent other JS from running between when the script stops and resumes JS execution
   • This excludes JS associated with browser work like event processing, rAF callbacks etc

This proposal focuses on constraints 1, 3 & 4, and ignores 2 and 5, which will be addressed independently.

The fifth constraint is interesting - in order for work which is incentivized to finish quickly (e.g., ads script) to be able to adopt this API and improve responsiveness to input, we need some way to prevent arbitrary javascript from executing between when script yields and when it is rescheduled.

Privacy and Security

The primary concerns with this API stem from the correctness of input event attribution. UAs must make sure they don't leak information about pending events dispatched to other frames by performing necessary hit-testing and focus attribution. For maximum utility, this should be done off the event loop so that running JS does not have to yield in order to detect input.

Implementors must take care to avoid leaking inputs across different origins, particularly during iframe movement or focus changes. Under no circumstances should input detected by an agent of origin A be dispatched to an agent of origin B -- this would allow origin A to determine if origin B had a DOM event dispatched, which violates the same-origin policy. Implementors may work around this by being consistent with hit testing dispatch for inputs detected using isInputPending as well as for DOM event dispatch, or discarding events where inconsistencies are inevitable (e.g. cases where off-main-thread hit testing is insufficient).

User agents may want consider a combination of off-main-thread based hit testing (e.g. done on the compositor thread, if present) and keyboard focus to determine the appropriate document to mark as having input pending. By performing hit testing online, calls to isInputPending can be made faster, safer from timing attacks, and thus more effective for scheduling purposes.