Bug Tracker

Changes between Initial Version and Version 1 of Ticket #10168


Ignore:
Timestamp:
Aug 30, 2011, 11:20:42 AM (12 years ago)
Author:
dmethvin
Comment:

Those are some great questions!

Your analysis is basically correct. There are a few related tickets like #3827 as well that show other issues with the .trigger() design peeking through. I think the general team consensus is that inline handlers are both bad practice and a pain in our butts due to issues like this.

I suspect the reason this may not be reported very often is that the most common way for people to use inline handlers is to prevent the default action, which means they never see the double triggering.

If we're going to fix this and continue supporting inline handlers, we have to run them in the trigger loop up front so they can stop propagation and prevent default. In that case we'd need to figure out some way to remove/restore all the inline handlers just like we do for the target -- really messy for something we don't even want people to do.

Either that or we have to eliminate that trigger loop *entirely* for native events (still need it for custom events) and have the browser do the propagation. You're basically proposing that with the evt.target[event.type] test. That brings issues like #3827 into play, which would be a major breaking change.

As for capture behavior, jQuery doesn't support it via the external API. It's used in a couple of places for special events (see focusin and focusout).

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10168

    • Property Status changed from new to open
  • Ticket #10168 – Description

    initial v1  
    2828Another 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.
    2929
    30 Seems to be related to the following tickets : [ticket: 6593], [ticket: 6705]
     30Seems to be related to the following tickets : #6593, #6705
    3131
    3232Here's the use case : == http://jsfiddle.net/FrKyN/19/ ==