Этот вопрос связан с обработкой событий Javascript и управлением потоком, но это один шаг дальше.Вопрос, который остается без ответа: когда событие запускается и управление возвращается браузеру, может ли браузер решить сначала обрабатывать другие события (запущенные другими сценариями или действиями пользователя) (A), или он всегда будет обрабатывать мое событие напрямую (Б)?
Вопрос важен, потому что в случае (Б) вы можете полагаться на то, что между срабатыванием события и обработчиком события ничего не изменилось, а (А) не дает никаких гарантий.
Мое первое предположение: (B), как еще могли бы работать stopPropagation() и preventDefault()? Но, если подумать, это не является веским доказательством.
Реальный пример этой проблемы. Я модифицирую редактор форматированного текста (привет) и хочу, чтобы он имел следующие характеристики:
Теперь в большинстве случаев, когда вы закрываете диалоговое окно, вы хотите, чтобы фокус возвращался к #txt.Но в случае, когда открыто диалоговое окно и вы щелкаете в другом месте страницы, редактор закроется и вызовет панель инструментов, в том числе и диалоговое окно для закрытия. Если в этом случае диалог вернет фокус редактору, он снова активирует редактор.
Насколько я сейчас понимаю, порядок обработки событий как минимум детерминирован. Невозможно, чтобы одно событие получило задержку, а другое обрабатывалось раньше. Это то, что подразумевается под «синхронным». Исключение составляют, конечно, такие события, как загрузка файла.
С точки зрения компонента программы, скажем, диалога, ситуация может быть совершенно непредсказуемой. Он может привязать обработчик к событию открытия, а затем вызвать диалог ("открыть"), но между вызовом и обработчиком может произойти что угодно, хотя бы потому, что у редактора есть обработчик событий для того же события.
Итак, мой вывод: 1) да, это предсказуемо, но 2) для реализации этого требуется сложная архитектура.