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