self.navigator.scheduling vs self.scheduler

[Jamesernator]

As currently proposed and implemented in a Chrome origin trial we now have two separate locations for scheduling information self.navigator.scheduling and self.scheduler.

I think it would be better if they simply shared the same interface rather than separating these highly related features into two different places.

e.g.:

scheduler.postTask(async () => {
  while (true) {
    if (scheduler.isInputPending() || scheduler.isFramePending()) {
      await scheduler.yield("background");
    }
    // do work
  }
}, { priority: "background" });

[shaseley]

I agree that ideally these both be accessible from the same location. My preference is window given task queues and related scheduling are per-agent. It's also shorter as window can be omitted.

@acomminos do you have context for why isInputPending is on navigator? Looking at the spec, in step 4 of the isInputPending method it looks like the scope is narrowed to the relevant agent. Could this work just as well if it was routed through window? I'm wondering if as part of this work we could think about moving this to window.scheduler (if that's what we spec it as). One path would be to have navigator.scheduling.isInputPending route to window.scheduler.isInputPending and deprecate the navigator path.

[acomminos]

Could this work just as well if it was routed through window?

The original explainer actually had isInputPending on window, IIRC.

The only justification I can think of for navigator is that since the API is able to detect other same-origin targeted inputs outside of a single window/frame's scope, it could be argued that detected inputs are not under the direct ownership of a single window. But that argument doesn't strike me as particularly strong.

cc @n8schloss / @spanicker -- do you recall why the move to navigator was proposed?

One path would be to have navigator.scheduling.isInputPending route to window.scheduler.isInputPending and deprecate the navigator path.

This sounds good to me.