Looking at the
event.js file, in the
jQuery.event.trigger method, it seems that a triggered event is first bubbled manually, then triggered natively to allow default browser behaviours. The problem occurs when you add a listener without
jQuery, like an inline
As I understand it, it kind of looks that way :
current = evt.target;
execute current jquery handlers
execute current inline handler
current = current.parentNode
while not evt.isPropagationStopped
if not evt.defaultPrevented
deactivating jquery handlers
deactivating evt.target inline handler but not ancestor ones
So, if the event is not
defaultPrevented, the upward inline handlers are executed twice. If it is, listeners added using native
attachEvent|addEventListener methods would be triggered but delayed compared to the
jQuery handlers, and also the
evt.isPropagationStopped eventually setted by a previous
jQuery handler would be ignored.
jQuery.event.triggered flag, which seems to deactivate the
jQuery shared handler, can be used in the inline handlers as well, why not doing something like this :
bubble manually ...
I'm although curious about the way you will handle the
DOM 3 capture behaviour.
Another thought : I can imagine how tough it is to maintain the consistency of the lib, but the more I'm reading it, the more I'm thinking : if I'm building a web app using
jQuery, I shouldn't use anything else which is not build against the same
jQuery, otherwise I would encounter strange behaviours. It would be nice to inform users about the interactions and caveats somewhere in the documentation. If it is, my bad, I'll do better reading it next time.
Seems to be related to the following tickets : #6593, #6705
Here's the use case : == http://jsfiddle.net/FrKyN/19/ ==
Chromium 13 and