1759128 - task priorities in Gecko

Status: NEW

(Core :: DOM: Core & HTML, enhancement)

Description

[Roberto Vidal [:_rvidal]]

Steps to reproduce:

const { port1, port2 } = new MessageChannel();

port1.onmessage = () => console.log('message');


setTimeout(() => console.log('timeout'));
port2.postMessage(null);

Actual results:

timeout
message

Expected results:

Strictly speaking this is not a bug report, but a question. I was suggested to post here anyway.

TL;DR: does Gecko have a "reliable" way to enqueue tasks with different priorities?

I work on StackBlitz trying to get WebContainer to work on Firefox. WebContainer is a finicky system that benefits from having as much insight from the underlying browser internals as possible (as bad as an idea as that might sound).

The above code prints messages in the opposite order in Chrome:

message
timeout

I imagine that what we're observing here is the legit differences between engines included in https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model :

Let taskQueue be one of the event loop's task queues, chosen in an implementation-defined manner [...]

This difference is somewhat surprising because MessageChannel is the usual mechanism used to polyfill setImmediate [1] (in a worker at least), and my default assumption was that the MessagePort queues would have higher priority than the timer queues. This does not seem to be the case in Gecko. So my question is: is there a reliable way of enqueuing tasks (not microtasks) with different priorities in Gecko?

(Note that "reliable" for us is somewhat flexible. We're not asking for any kind of commitment, just a description of the current implementation).

I did some perusing through Gecko's source (TaskCategory.h and such) but couldn't really find anything conclusive.

[1] https://github.com/YuzuJS/setImmediate/blob/master/setImmediate.js

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox Build System::Task Configuration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Andrew Halberstadt [:ahal]]

Bugbug is mistaken :)

Comment 3

[Rares Doghi, Desktop QA]

I'm opening this as an Enhancement since its not an actual defect, hopefully one of our devs can take a look and answer these questions.
I'm not sure which is the correct component for it though, if its not the correct one please move it to a more suitable component.

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

Looks like a question for the Spidermonkey folks

Comment 5

[Ted Campbell [:tcampbell]]

Sorry for redirecting this again, but the DOM team folks manage both the MessageChannel code and the event loops. They might have more insight into the history of this and what is possible.