Хороший вопрос. Я хотел бы сказать «да». Я не могу.
Считается, что JavaScript обычно имеет один поток выполнения, видимый для сценариев (*), поэтому при вводе встроенного сценария, прослушивателя событий или тайм-аута вы будете полностью контролировать, пока не вернетесь с конца своего блока или функция.
(*: игнорирование вопроса о том, действительно ли браузеры реализуют свои движки JS, используя один поток ОС, или WebWorkers вводят другие ограниченные потоки выполнения.)
Однако, в действительности это не совсем верно , в подлых противных отношениях.
Наиболее распространенный случай - это немедленные события. Браузеры сработают сразу же, когда ваш код что-то заставит их вызвать:
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">
Результаты log in, blur, log out на всех, кроме IE. Эти события не просто запускаются, потому что вы вызвали focus() напрямую, они могут произойти, потому что вы вызвали alert(), или открыли всплывающее окно, или что-нибудь еще, что перемещает фокус.
Это также может привести к другим событиям. Например, добавьте прослушиватель i.onchange и введите что-нибудь во входные данные до того, как вызов focus() разфокусирует его, и порядок записи будет log in, change, blur, log out, за исключением Opera, где он log in, blur, log out, change, и IE, где это (даже менее объяснимо) log in, change, log out, blur.
Аналогичным образом вызов click() для элемента, который его предоставляет, вызывает обработчик onclick сразу во всех браузерах (по крайней мере, это соответствует!).
(здесь я использую свойства прямого обработчика событий on..., но то же самое происходит с addEventListener и attachEvent.)
Существует также множество обстоятельств, при которых события могут запускаться, пока ваш код пронизан, несмотря на то, что вы не сделали ничего , чтобы спровоцировать его. Пример:
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>
Нажмите alert, и вы получите модальное диалоговое окно. Больше сценарий не выполняется, пока вы не закроете этот диалог, да? Нету. Измените размер главного окна, и вы получите alert in, resize, alert out в текстовой области.
Вы можете подумать, что невозможно изменить размер окна, пока модальное диалоговое окно открыто, но это не так: в Linux вы можете изменить размер окна так, как вам нравится; в Windows это не так просто, но вы можете сделать это, изменив разрешение экрана с большего на меньшее, где окно не помещается, что приводит к изменению его размера.
Вы можете подумать, что только resize (и, возможно, еще несколько, как scroll) могут срабатывать, когда пользователь не имеет активного взаимодействия с браузером, потому что сценарий является многопоточным. И для одиночных окон вы можете быть правы. Но это все подходит к концу, как только вы выполняете межоконный сценарий. Для всех браузеров, кроме Safari, который блокирует все окна / вкладки / фреймы, когда какой-либо из них занят, вы можете взаимодействовать с документом из кода другого документа, работая в отдельном потоке выполнения и вызывая любые связанные обработчики событий для огонь.
Места, где могут быть сгенерированы события, которые вы можете вызвать, пока сценарий все еще находится в потоке:
когда модальные всплывающие окна (alert, confirm, prompt) открыты во всех браузерах, кроме Opera;
во время showModalDialog в браузерах, которые его поддерживают;
диалоговое окно «Сценарий на этой странице может быть занят ...», даже если вы решите позволить сценарию продолжать работу, позволяет запускать такие события, как изменение размера и размытие, и обрабатывать их даже во время выполнения сценария. находится в середине занятого цикла, кроме Opera.
Некоторое время назад для меня, в IE с плагином Sun Java, вызов любого метода в апплете мог позволить запускать события и повторно вводить сценарий. Это всегда была ошибка, чувствительная ко времени, и, возможно, Sun исправила ее с тех пор (я, конечно, надеюсь).
наверное больше. Прошло много времени с тех пор, как я протестировал это, и с тех пор браузеры стали более сложными.
Таким образом, для большинства пользователей JavaScript, как правило, имеет строгий поток выполнения, управляемый событиями. На самом деле такого не бывает. Непонятно, насколько это просто ошибка, а какой умышленный дизайн, но если вы пишете сложные приложения, особенно с кросс-оконными / фрейм-скриптовыми сценариями, есть все шансы, что они могут вас укусить - и периодически, трудные для отладки способы.
Если худшее приходит к худшему, вы можете решить проблемы параллелизма, косвенно реагируя на все события. Когда событие приходит, поместите его в очередь и обработайте очередь по порядку позже, с помощью функции setInterval. Если вы пишете фреймворк, который вы собираетесь использовать в сложных приложениях, это может быть хорошим шагом. postMessage также, мы надеемся, поможет в будущем избавиться от боли при написании документов.