Clarify yield-priority-timers.any.js

[sefeng211]

For https://github.com/web-platform-tests/wpt/blob/master/scheduler/tentative/yield/yield-priority-timers.any.js, I am having a hard time understanding the expected behaviour.

My interpretation is that scheduler.yield() dispatches a task for its promise to resolve, so when the first setTimeout handler run, it'll dispatch a task for this, and this task can possibly not be run until the second and the third setTimeout handlers to finish. I am not sure how the spec enforces the task for scheduler.yield() to run first.

[shaseley]

This is related to #67. Right now there's a note in the spec indicating what the intent is (https://wicg.github.io/scheduling-apis/#sec-patches-html-event-loop-processing), but at TPAC discussions it was agreed that we should specify this more rigidly (basically update the spec to match that test). I'm planning to start migrating things to WHATWG/HTML this quarter, and part of that work will be to fix this issue. I'll cc you on PRs and such when I make some progress (it might be a couple weeks before I can get to this).

[mmocny]

scheduler.yield() dispatches a task for its promise to resolve, so when the first setTimeout handler run, it'll dispatch a task for this, and this task can possibly not be run until the second and the third setTimeout handlers to finish.

Just to make it super clear: yield() is expected to be guaranteed to run before the second and third setTimeout tasks.

Here's roughly how I expect that test to function:

• Task Queue starts with no tasks in the task queue
• First setTimeout called from promise, so task queue is [setTimeout1]
• Second and third setTimeout called, so task queue is [setTimeout1, setTimeout2, setTimeout3]
• First task popped and scheduled, task queue becomes [setTimeout2, setTimeout3]
• As part of running setTimeout1, we yield(), this schedules a new task at the front of the queue (alternatively: into a new queue with elevated priority, effectively the same), so the task queue becomes [yield1, setTimeout2, setTimeout3]
• ...and so on.

The test is not meant to be ambiguous, and while the specific task priorities of setTimeout and other apis needs better specification, I think that the existing wording for yield should have made this clear?

[mmocny]

Quickly passing over existing wordings, I guess we currently vaguely allow for any UA-defined "higher priority" tasks to get scheduled before the yield continuation.

This test is a little simplified in that all the tasks are timer tasks, presumably that implies the all have equal priority, that implies that the yield continuation should always be scheduled first -- even without formally cleaning up setTimeout and other scheduling mechanisms' priority relative to other tasks?

[sefeng211]

I wonder if there's a confusion around task-source. setTimeout uses its own task source.

If the task scheduled by yield uses the same task source, it'll be dispatch to the end of the task queue, so it'll be run after the handlers for setTimeout2, and setTimeout3.

If the task scheduled by yield uses a different task source, then it could also be run after the handlers for setTimeout2 and setTimeout3. Do I miss anything?

[mmocny]

Can you clarify if this is a general question about how the API expectations are meant to work, and/or feasibility of implementation -- or if this is about specific spec text feedback?

Do I miss anything?

The yield() continuation task source should have a slightly higher priority, so it should not run after the handlers for setTimeouts.

In Chromium the yield() continuation priorities fall between the other priority types i.e. when a user-visible task yields, its continuation will run between other user-blocking and other user-visible (default) priority tasks.

I think Scott presented this graphic at TPAC:

[shaseley]

I added this test with the intent to rigidly specify the order between timers and yield, but we ended up just with the spec note (and I never removed the test). This test matches Chromium behavior (illustrated in that graphic), but the spec is indeed ambiguous (the note implies this, but it's not required). During the joint WHATWG/WebPerfWG conversation at TPAC, we determined needs to be specified more rigidly, so I consider this a spec bug, which I'm working on fixing this quarter.

[sefeng211]

Okay, thanks folks. That graph clarified this for me. Sorry I totally forgot about that graph.

Making this test to pass in Gecko requires some extra works because when Gecko's timer decides to run setTimeout handlers, it'll run all handlers that pass the delay, without allowing other tasks to squeeze in between (except microtasks). So I'll need to figure something out...

I'll leave this issue open for us to make it clearer in the spec.

Thanks again!