[kick]

Remember when a tab freezing didn't make Firefox's UI chrome unresponsive? I do, too.

[floatboth]

I remember when it did — before the "Electrolysis" project, when everything ran in one process. This was quite a long time ago already.

[skrebbel]

I'd assume that the Firefox chrome runs in its own process. Why would the switch to web components for the chrome change that?

[amelius]

Every tab's UI (and the main UI) can still run in a different thread or process, I suppose ...

[MikusR]

When was that?

[pessimizer]

Web 4.0 is the internet of race conditions. Thanks, javascript everywhere.

[hombre_fatal]

I don't get it. Javascript would have categorically improved on this compared to more traditional multi-threaded solutions.

[GrayShade]

You can still have race conditions in single-threaded async code.

[cjones26]

Well I don't think that could technically be considered a race condition, as it's clearly a design problem in the code causing what would appear to be a "pseudo" race condition.

[GrayShade]

Why not? It is a race condition, just like TOCTTOU is a race condition that doesn't necessarily involve threads.

Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.

[minitech]

And “Javascript would have categorically improved on this compared to more traditional multi-threaded solutions” remains true nevertheless.

[cjones26]

What? JavaScript is a single threaded language...

[Yoric]

And despite this, I've encountered lots of race conditions in JavaScript, thanks to the magic of async programming. Harder to debug than multi-threaded ones, too.