C'est une bonne question. J'adorerais dire "oui". Je ne peux pas.
JavaScript est généralement considéré comme ayant un seul thread d'exécution visible par les scripts (*), de sorte que lorsque votre script en ligne, l'écouteur d'événements ou le délai d'expiration est entré, vous gardez un contrôle total jusqu'à ce que vous reveniez de la fin de votre bloc ou de votre fonction.
(*: ignorer la question de savoir si les navigateurs implémentent réellement leurs moteurs JS à l'aide d'un thread OS, ou si d'autres threads d'exécution limités sont introduits par WebWorkers.)
Cependant, en réalité, ce n'est pas tout à fait vrai , de façon méchante et sournoise.
Le cas le plus courant est celui des événements immédiats. Les navigateurs les déclenchent immédiatement lorsque votre code fait quelque chose pour les provoquer:
var l= document.getElementById('log');
var i= document.getElementById('inp');
i.onblur= function() {
l.value+= 'blur\n';
};
setTimeout(function() {
l.value+= 'log in\n';
l.focus();
l.value+= 'log out\n';
}, 100);
i.focus();
<textarea id="log" rows="20" cols="40"></textarea>
<input id="inp">
Résultats log in, blur, log outsur tous sauf IE. Ces événements ne se déclenchent pas uniquement parce que vous avez appelé focus()directement, ils peuvent se produire parce que vous avez appelé alert()ou ouvert une fenêtre contextuelle ou tout autre élément qui déplace le focus.
Cela peut également entraîner d'autres événements. Par exemple, ajoutez un i.onchangeécouteur et tapez quelque chose dans l'entrée avant que l' focus()appel ne le mette au point, et l'ordre du journal est log in, change, blur, log out, sauf dans Opera où il se trouve log in, blur, log out, changeet IE où il se trouve (encore moins de manière explicite) log in, change, log out, blur.
De même, faire appel click()à un élément qui le fournit appelle onclickimmédiatement le gestionnaire dans tous les navigateurs (au moins c'est cohérent!).
(J'utilise on...ici les propriétés du gestionnaire d'événements direct , mais la même chose se produit avec addEventListeneret attachEvent.)
Il y a aussi un tas de circonstances dans lesquelles des événements peuvent se déclencher pendant que votre code est enfilé, bien que vous n'ayez rien fait pour le provoquer. Un exemple:
var l= document.getElementById('log');
document.getElementById('act').onclick= function() {
l.value+= 'alert in\n';
alert('alert!');
l.value+= 'alert out\n';
};
window.onresize= function() {
l.value+= 'resize\n';
};
<textarea id="log" rows="20" cols="40"></textarea>
<button id="act">alert</button>
Frappez alertet vous obtiendrez une boîte de dialogue modale. Plus aucun script ne s'exécute jusqu'à ce que vous fermiez ce dialogue, oui? Nan. Redimensionnez la fenêtre principale et vous obtiendrez alert in, resize, alert outdans la zone de texte.
Vous pourriez penser qu'il est impossible de redimensionner une fenêtre alors qu'une boîte de dialogue modale est ouverte, mais ce n'est pas le cas: sous Linux, vous pouvez redimensionner la fenêtre autant que vous le souhaitez; sous Windows, ce n'est pas si facile, mais vous pouvez le faire en changeant la résolution de l'écran d'une plus grande à une plus petite où la fenêtre ne rentre pas, ce qui provoque son redimensionnement.
Vous pourriez penser, eh bien, ce n'est que resize(et probablement quelques autres scroll) que peut se déclencher lorsque l'utilisateur n'a pas d'interaction active avec le navigateur car le script est enfilé. Et pour les guichets uniques, vous avez peut-être raison. Mais tout va au pot dès que vous effectuez des scripts inter-fenêtres. Pour tous les navigateurs autres que Safari, qui bloque toutes les fenêtres / onglets / cadres lorsque l'un d'entre eux est occupé, vous pouvez interagir avec un document à partir du code d'un autre document, en exécutant dans un thread d'exécution distinct et en provoquant la gestion de tous les gestionnaires d'événements associés. Feu.
Les endroits où les événements que vous pouvez faire générer peuvent être déclenchés pendant que le script est toujours enfilé:
lorsque les popups modales ( alert, confirm, prompt) sont ouverts, dans tous les navigateurs , mais Opera;
pendant showModalDialogsur les navigateurs qui le prennent en charge;
la boîte de dialogue "Un script sur cette page peut être occupé ...", même si vous choisissez de laisser le script continuer à s'exécuter, permet aux événements tels que le redimensionnement et le flou de se déclencher et d'être gérés même lorsque le script est au milieu d'un boucle occupée, sauf dans Opera.
il y a quelque temps pour moi, dans IE avec le plugin Sun Java, appeler n'importe quelle méthode sur une applet pouvait permettre aux événements de se déclencher et de réécrire le script. C'était toujours un bug sensible au timing, et il est possible que Sun l'ait corrigé depuis (je l'espère certainement).
probablement plus. Cela fait un moment que je n'ai pas testé cela et les navigateurs sont devenus plus complexes depuis.
En résumé, JavaScript apparaît à la plupart des utilisateurs, la plupart du temps, comme ayant un thread d'exécution unique piloté par les événements. En réalité, il n'a rien de tel. On ne sait pas exactement dans quelle mesure il s'agit simplement d'un bogue et de la conception délibérée, mais si vous écrivez des applications complexes, en particulier des applications cross-window / frame-scripting, il y a toutes les chances que cela puisse vous mordre - et de manière intermittente, méthodes difficiles à déboguer.
Si le pire arrive au pire, vous pouvez résoudre les problèmes de concurrence en indirectant toutes les réponses aux événements. Lorsqu'un événement arrive, déposez-le dans une file d'attente et traitez-la dans l'ordre plus tard, dans une setIntervalfonction. Si vous écrivez un framework que vous avez l'intention d'utiliser dans des applications complexes, cela pourrait être une bonne chose. postMessageespérons également apaiser la douleur de l'écriture de documents croisés à l'avenir.