Bug Tracker

Ticket #11498 (closed bug: patchwelcome)

Opened 3 years ago

Last modified 11 months ago

Click event inconsistent firing on nested elements

Reported by: whitters Owned by: whitters
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.1
Keywords: Cc:
Blocking: Blocked by:

Description

When you bind two nested elements' click handler the events should only fire when both the mouse down and mouse up event fires within the bounds of that element. If a mousedown originates in A and the mouseup originates in A > B then the mouseclick event should not fire on either elements.

This is is true in both Firefox 10.0.2 and Chrome 17. However, IE7-9 will fire a click event on the parent element regardless of mousedown and mouseup origins. Mousedown on A > B and mouseup on A, as well as Mousedown on A and mouseup on A > B, will result in a click event firing on A.

In all browsers a click on solely A > B will result in click events for both A > B and A as per normal event propagation.

I'm not sure how this can be distilled down to a non-interactive test since this involves non-trivial mouse input.

As I'm not familiar with what is intended to be standard behavior I submit this as behavior that should be, but is not, normalized by jQuery.  http://jsfiddle.net/hSuDa/

Change History

comment:1 Changed 3 years ago by rwaldron

  • Owner set to whitters
  • Status changed from new to pending

Can you confirm this:  http://jsfiddle.net/rwaldron/X6yvg/

I did this first manually, then added the triggers. The behaviour is the same in Chrome, Firefox, IE7, 8, 9 - all of them log:

  • outer click
  • inner click
  • outer click

Which was the same when tested manually

comment:2 Changed 3 years ago by whitters

  • Status changed from pending to new

The issue is when the mousedown and mouseup events don't originate in the same element. As in, click down in the outer box, then drag into the inner box, then release in the inner box. This should not generate a click event on either element.

Your test simply reports click events where both the mousedown and mouseup event would hypothetically occur in the same element, though I'm not familiar with whether jQuery generates such mousedown and mouseup events when triggering a 'click'.

comment:3 Changed 3 years ago by dmethvin

  • Status changed from new to pending

I see the behavior you're describing, but it seems outside what jQuery core should handle. It starts to get into intent, and core isn't in the best position to determine intent because it can involve time, space, and sequences of events.

Do you have some sort of solution in mind? Keep in mind that the current behavior has been acceptable for five years, even if it's inconsistent.

comment:4 Changed 3 years ago by whitters

  • Status changed from pending to new

The solution I used locally is incredibly kludgey. I consume all click events following a mouseup event for 10ms. The edge case being someone clicks faster than 10ms.

The best I could find in the w3 standard was the definition of a 'click' event as per the DOM Level-2 standard.

The click event occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location.

Same location has, as per Chrome and Firefox, become to be interpreted as a same element. As I understand one of jQuery's efforts is to provide a consistent and standard event model. As events registered via .on with jQuery fire in a decidedly non-standard and non-consistent manner across browsers it should be expected to be normalized by the library as other event behaviors have been.

comment:5 Changed 3 years ago by dmethvin

  • Status changed from new to closed
  • Resolution set to patchwelcome

I don't think there's some magic-wand solution we can apply here. If the browser fires mousedown with one event.target but mouseup with another event.target and then click with one or the other, I think you'd need to take it up with the browser maker. The only kind-of-solution I could think of was one like yours, but then we are starting to hide the browser's real behavior from the developer in the name of consistency.

So...I don't think there is a solution but if anyone would like to suggest one that does not have ugly implications we're open to it.

comment:6 Changed 11 months ago by anonymous

Note: See TracTickets for help on using tickets.