Сообщение от Octane
|
глядя на код я не понял, как узнать, что bubbling фаза закончилась и пора её в обратном порядке запускать.
|
попытаюсь объяснить.
При навешивании событий на какой либо элемент при помощи addEventListener моя библиотека смотрит, есть ли у нее уже навешанное такое событие на верхний элемент(document) если видит проверка дала отрицательный результат, то она тоже навешивает такое же событие на на самый верхний элемент(document) то-есть раньше чем то что навешивает разработчик. То-есть получается что событие в библиотеке повешено самым первым, что и дает возможность узнать что фаза bubbling закончилась.
К примеру вы где-то в своем коде пишите:
<div id="lala"></div>
<script>
document.getElementById('lala').addEventListener( 'click', function( e ) {
// здесь не нужно обращаться к window.event
// первый параметр вернет этот же объект но с исправлениями
// и дополнительными методами
alert( e ); // [object Event]
}, true );
</script>
по сути обычное действие.
Далее при вызове метода addEventListener моя библиотека делает действия примерно в таком порядке:
ищет у себя в стеке уже про инициализированный планировщик на это событие.
если находит, то просто вешает событие через attachEvent при этом обертывая вызов функции что передали вторым аргументом в некий прокси метод, который и будет вызван при клике. Если не находит, то создает планировщик для этого события. В нашем случае это click и слушает самый верхний элемент документа.
Далее при срабатывании события вызываются прокси метод, на элементе получившем событие, а тот в свою очередь кладет элемент в стек, что бы потом планировщик с ним далее мог работать.
Самым последним получает событие сам верний элемент и в нашем случае тот самый планировщик, так как планировщик был повешен самым первым и поэтому срабатывает самым последним, то-есть он точно знает что за ним более нет слушателей.
Ну а потом планировщик уже обрабатывает тот самый кеш, то-есть в кеше лежит список элементов которые должны получить событие. Вот по этим элементам он и проходит обрабатывая при этом результативные значения, такие как stopPropagation, preventDefault и т.д. А после окончания обработки, очищает кеш для следующего наполнения по событию.
Сообщение от Octane
|
Если не срабатывает fireEvent, то listener'ы запускаются синхронно?
|
Да, синхронно, собственно так же как и в случае корректного срабатывания fireEvent.
Сообщение от Octane
|
Может фейковый эвент инициировать, чтобы ошибка в listener'е не останавливала выполнение кода. Когда fireEvent ошибку выдаёт?
|
В смысле, не совсем понял вопроса.
Сообщение от Octane
|
В фазе capturing не имеет смысла обращаться к window.event, чтобы достать дополнительную информацию?
|
да можете обращаться, но это не обязательно, ибо в вашу функцию обработчика придет первый параметр именно этого экземпляра, но только с дополнительными методами и корректировками.
Сообщение от Octane
|
вообще нельзя в Element.prototype ничего добавить для IE7?
|
Можете добавлять что угодно, все это будет появляться у элементов