Why do "Alert", "confirm" and "prompt" lock the loading independent of the definition order?

Question

I’d like to understand why, when we use the functions alert, confirm or prompt, they always cause a kind of "freeze" on the screen.

For example, I have a alertand then I have a div with a defined style. The style of div will only be visible after I close the alert.

<script>alert('oi')</script>
<div style="background-color: black;height: 50px">
  
</div>

I thought it was about order as things were defined, but it doesn’t seem like that:

<div style="background-color: black;height: 50px"></div>

<script>alert('oi')</script>

I’ve also noticed that in other cases, when you have a dynamic definition of creating elements, the same thing happens.

In the example below, I already have one element created, however, after a while I create another dynamically and then call the function confirm.

setTimeout(function () {
  
  var div = document.createElement('div');
  div.innerHTML = 'Nova div';
  document.body.appendChild(div) 
  confirm('oi')
}, 200)

<div style="background-color: black;height: 50px"></div>

The result is that even I define document.body.appendChild before confirm, the appendChild appears to be running only after the closing of confirm.

• Why Javascript’s native dialogs "lock" the process of creating elements and style settings?

• Since sometimes this causes an unwanted "whiteness" on the screen, as I might call it alert, confirm or prompt without interfering with page loading?

Answer 1

Why "Alert", "confirm" and "prompt" lock loading?

Because it’s a feature of language...

This functionality was created like this, in the time of the dinosaurs, and it hasn’t changed anymore because everyone knows it works like this and changing it would break code that has this characteristic of language. As Javascript runs in a single thread and these methods wait for user response, everything stops waiting for user action.

The reason the style is not shown is because HTML is not shown before Javascript is read. No style, no content. It’s the way the browser mounts the page. (example)

Answer 2

This is because the original JS is synchronous and the JS needs to lock the execution on the confirm, for example, so that your result is placed in the variable and can be used right at the bottom line.

On the second question: the browser is divided into several parts, one of them is the JS engine and the other is the part that draws things on the screen. They are not synchronous. The JS may have shown something on the screen, but the browser will only draw even on the screen when the next refresh happens, and this depends on various things, including the device’s ability to draw things on the screen quickly.

There is a new function requestAnimationFrame which allows you to perform a function together when the browser is doing refresh.

Answer 3

I think the answers posted already respond well. Just to complement, as an alternative you can create a dialog that does not block. In general will use Webworkers or Promisses. What now has become very standard.

The jQuery does this.

Answer 4

In fact this behavior depends on the browser Voce is using.

I will now describe the behavior for the most used browsers:

Chrome(1) - Chrome Version 54.0.2840.99 m (64-bit)

Firefox(2) - Firefox 49.0.2

Edge(3) - Microsoft Edge 38.14393.0.0

Opera(4) - Opera 41.0.2353.56

IE(5) - Internet explorer 11.447.14393.0

Safari(6) - Safari 5.1.7 (7534.57.2)

Chrome on android(7) - Chrome 53.0.2785.124

It was to have tested also with firefox on android and safari on Ios but it is not possible to run stackexchange snippet code on them.

Scenario 1 - <script> before <div> - All browsers have identical behavior

Scenario 2 - <div> before <script>

1. Shows message. Locks. Shows div

2. Shows both practically at the same time

3. Shows both practically at the same time

4. Shows message. Locks. Shows div

5. Shows both practically at the same time

6. Shows message. Locks. Shows div

7. Shows message. Locks. Shows div

Scenario 3 - With timeout. all browsers have the same behavior.

We can then conclude that it ultimately depends on the javascript browser engine implementation / DOM loading in scenario 2.

A question very related to this in the English community, ask where we should put blocks of <script> in html.

The answer given is that it should be at the end of the html document for the gift to be loaded. and your javascript can access any element of your page.

That is if the gift is loaded and presented before your script (as it happens in firefox edge and ie) Voce has the behavior described (in which both appear at the same time), or the browser interprets the script and runs it.

Answer 5

Because those functions that you refer to, internally have a set of subroutines and one of them is : "For everything! Shows Alert and expects a user input", and each will have its own peculiar behavior...