setTimeout callbacks have different execution orders in Firefox and Chrome

The explanation: It doesn't matter.

The details of when deferred "messages" are added to the event loop message queue are implementation details, not documented guarantees. By the time your function yields control back to the event loop, all of your setTimeout call are eligible to execute (three of them were scheduled to run immediately, one of them was scheduled to run in 100 ms) and you've guaranteed it's been at least 400 ms since you scheduled it.

The difference between the two could be as simple as whether they choose to look for deferred tasks that have become ready (to move from the deferred queue to the main "ready to go" message queue) immediately before or immediately after new items are inserted in the main message queue. Chrome chooses to move immediately after 3 is scheduled (so 3 goes in, then the deferred 2), Firefox immediately before (moving in 2 before it puts 3 in).

Both of them could change in the next release without violating any documented guarantees. Don't rely on it, don't expect it to be stable. While immediately scheduled tasks are guaranteed to execute in FIFO order, there are no guarantees on when deferred tasks get moved onto the "ready-to-go" message queue. The spec seems to requires that 1, 3 and 4 execute in that order (since they were all immediately ready, not deferred), with only the ordering of 2 being flexible, but even that isn't a true guarantee; it can get weird with the various ways in which an "immediate" setTimeout task may not actually be scheduled immediately.

You may be interested in the MDN docs on why setTimeout can take longer than expected; it explains by side-effect a lot of how the event loop works, even as it carefully provides no guarantees on the details you're exploring.

I can't give you an full detailed explanation, but the second paramter of setTimeoput and setInterval doesn't mean, it will exactly execute it at that time. They will put it in a queue, so the background can execute it.

The browser has a lifecycle when to execute specific steps to update the data and the styles.
I can only send you this youtube link, that helped me to learn more about it:

https://www.youtube.com/watch?v=MCi6AZMkxcU

1, 2, 3, 4 is the behavior that is expected.

The specs ask to

Wait until any invocations of this algorithm that had the same global and orderingIdentifier, that started before this one, and whose milliseconds is equal to or less than this one's, have completed.

So any call to setTimeout that were both made before, and had their milliseconds set to a lower value should be called first.

Firefox, Safari, and the current stable channel of Chrome all do this.

So when the event loop gains control again, it sees that all the timers are ready to be called, and it queues tasks for each, in this scheduled called order:

"1": scheduled-time = t=0 + 0   = 0
"2": scheduled-time = t=0 + 100 = 100
"3": scheduled-time = t=200 + 0 = 300
"4": scheduled-time = t=400 + 0 = 400

But, what Chrome apparently used to do and still does in its other branches is that they only do look at the milliseconds param to do the ordering and ignore the first "that started before this one" condition.
So in there we've got,

"1": milliseconds = 0
"3": milliseconds = 0
"4": milliseconds = 0
"2": milliseconds = 100

Below is a rewrite of this logic:

// We use a MessageChannel to hook on each iteration of the event loop
function postTask(cb) {
  const channel = postTask.channel ??= new MessageChannel();
  const { port1, port2 } = channel;
  port1.addEventListener("message", (evt) => { cb() }, { once: true });
  port1.start();
  port2.postMessage("");
}
const timers = new Set();
let ended = false; // So we can stop our loop after some time
function timeoutChecker() {
  const now    = performance.now();
  const toCall = Array.from(timers)
                  .filter(({ startTime, millis }) => startTime + millis <= now)
                  .sort((a, b) => a.millis - b.millis);
  while(toCall.length) {
    const timer = toCall.shift();
    timers.delete(timer);
    timer.callback();
  }
  if (!ended) {
    postTask(timeoutChecker);
  }
}
function myTimeout(callback, millis) {
  const startTime = performance.now();
  timers.add({ startTime, millis, callback });
}
// Begin our loop
postTask(timeoutChecker);

// OP's code
function run() {
  myTimeout(() => console.log("1"), 0);
  myTimeout(() => console.log("2"), 100);

  let start = Date.now();
  while (Date.now() - start < 200) {
    // do nothing
  }
  myTimeout(() => {
    console.log("3");
  }, 0);

  start = Date.now();
  while (Date.now() - start < 200) {
    // do nothing
  }
  myTimeout(() => {
    console.log("4");
  }, 0);
}

run();

// all should be done after 1s
setTimeout(() => ended = true, 1000);

As for why you sometimes may see "2" before "4" in Chrome and node.js, it's because they do clamp 0ms timeout to 1ms (thought they're working on removing this in Chrome). So when the event loop gains control at t=400, this log("4") timeout may not have met the timer condition yet.

Finally about Chrome's branch thing, I must admit I'm not sure at all what happens there. Running a bisect (against Canary branch) I couldn't find a single revision where the current stable branch behavior happens, so this must be a branch settings thing.