What code will run in the main browser thread?

Question

Chrome was the last of a large trio (IE, Firefox, Chrome) to refuse to make XMLHttpRequest synchronous calls in the "main thread" (as Firefox calls it). Some browsers also completely removed the ability to set the .widthCredentials option for synchronous requests in the main thread.

After searching around the world, I could not find enough information to determine exactly which code would work in the main thread and which would not.

Obviously, javascript included through the script tag (inline or with src) is in the main thread. And the synchronous XHR that works inside the asynchronous XHR callback will not work in the main thread.

But what about other scenarios? Mouse events, touch events, various document events? How to say without trying everything? It would be nice to avoid creating an asynchronous and reverse hell.

Please try a thorough answer.

Edit: W3C Specification Warning : Developers should not pass false for the async argument when the global JavaScript environment is the document environment because it has a negative effect on the end user interface. User agents are strongly advised to warn of such use in the developer’s tools and can experiment to eliminate the InvalidAccessError exception when it occurs, so that this function can ultimately be removed from the platform.

Edit 2: Clarification:

There are situations when the calling code must either wait until all racing simultaneous asynchronous calls end (using some counters or state tracking variables for each call), or they are chained using callbacks. Each situation sucks. For example, I have a JSONRPC client that needs to dynamically create callable functions by polling the reflection API.

Inside the hand, all the executable code (UI or NOT) needs to be executed inside the callback of another library, especially if it needs to be done on several pages, and if the library should behave like a simple definition (hide that the code works during the definition). This is just an example of complexity , I do not ask permission for it, but a general clear explanation of how the browser decides what is the main thread.

Answer 1

As you quoted the W3C spec , it's easy to explain what you are looking for after:

Developers should not pass false for the async argument if the Global JavaScript Environment is a document environment because it has harmful effects on the end user.

What they mean by document environment is explained in processing models :

This specification describes three types of global environments: a document environment, a dedicated worker environment, and a shared work environment. Special worker environments and general work environments are both types of worker environments.

Unless otherwise indicated, the global JavaScript environment is the document environment.

Thus, the "document environment" is the global JavaScript environment on the page, i.e. window you see. Each global JS environment is single-threaded . Everything (in fact, everything that you considered: mouse events, touch events, various document events) works in this environment. This is probably what Gekko considers to be the “main thread”.

It would be nice to avoid creating asynchrony and hell callback

Creating something asynchronous doesn't push work from the main thread. He simply puts it off, letting other events work while waiting. If there is an asynchronous api for what you want to do (i.e. handles in the background), use it. Make everything asynchronous.

There are enough methods (like promises!) To avoid the callback addon, which is just a sign of bad code.

Changing work from the main thread requires creating a new environment - a web worker. In this case, you can run as many synchronous XMLHttpRequests as you want, without breaking.

Answer 2

Each browser can implement its own streaming model as it sees fit. Different implementations will handle threads differently.

It is safe to say that if you want to block execution using JavaScript, you are doing something that you should not be. Even if you do not damage the user interface, browsers these days will force the user to interrupt your script. If you stay within a reasonable amount of processing lock in the script, this is not a problem. Synchronous XHR is something you should never do, since it is not necessary, and the time during which the thread is blocked is unpredictable.