Skip to main content

Bug Tracker

Side navigation

#3827 closed bug (fixed)

Opened January 12, 2009 09:50AM UTC

Closed November 24, 2012 07:53PM UTC

Last modified January 11, 2013 06:03PM UTC

Checkbox state inconsistent in click event handler

Reported by: skorpan Owned by: dmethvin
Priority: high Milestone: 1.9
Component: event Version: 1.2.6
Keywords: 1.9-discuss Cc:
Blocked by: Blocking:
Description

I'm not sure whether this is intended behavior or simply impossible to hack in pure JavaScript, but here goes nothing...

There is a significant difference between actually clicking an element and the triggering of the click event handlers bound to that element by JQuery. Attached to this ticket is a test script and its HTML to reproduce this "bug". What happens is:

1. I click the checkbox and see "State: ON" in the Firebug console. I click it a few times to verify that the correct state is always reported.

2. I click the button which in turn programmatically triggers the click event bound to the checkbox. Now the INCORRECT state is reported every time. This is probably due to the bound event handler being triggered before any internal behavior.

Attachments (3)
  • test-3827.html (1.6 KB) - added by dmethvin January 17, 2009 05:31PM UTC.

    event handling with jQuery trigger() and DOM events

  • test.html (0.5 KB) - added by skorpan January 12, 2009 09:51AM UTC.
  • test.js (0.2 KB) - added by skorpan January 12, 2009 09:51AM UTC.
Change History (33)

Changed January 15, 2009 01:20AM UTC by dmethvin comment:1

Can you explain what behavior you expected? Does it differ from raw Javascript behavior in some undesirable way? In general, all the handlers have to run before the browser's default action is taken. That's because the event handler can return false or e.preventDefault() to stop the default action.

Changed January 17, 2009 05:31PM UTC by dmethvin comment:2

I did some further work on this, and I agree with your analysis. Test case attached, checked in FF3 and IE8B2. The difference is because .trigger("click") calls the handler before the checkbox native click() method. A click on the checkbox calls the checkbox native click() method; that method causes the onclick event to fire and jQuery calls the handler.

See this thread for more discussion:

http://groups.google.com/group/jquery-dev/browse_frm/thread/39c3dabc8ac3569a

Changed April 22, 2009 03:33AM UTC by brandon comment:3

owner: brandon

Changed December 30, 2009 04:38AM UTC by dmethvin comment:4

Closed duplicate #5727 with another test case.

More info:

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-6043025

Note: During the handling of a click event on an input element with a type attribute that has the value "radio" or "checkbox", some implementations may change the value of this property before the event is being dispatched in the document. If the default action of the event is canceled, the value of the property may be changed back to its original value. This means that the value of this property during the handling of click events is implementation dependent.

It seems like most modern browsers change the checkbox state before calling the event handler, then revert it if the default action is cancelled.

Changed July 11, 2010 06:31PM UTC by dmethvin comment:5

summary: Click event triggered "too late"Checkbox state inconsistent in click event handler

Closed duplicate #6775.

Changed November 11, 2010 02:30AM UTC by dmethvin comment:6

resolution: → wontfix
status: newclosed

This behavior has been consistent since jQuery's first version, so there's no way we could change it without breaking significant existing code.

Changed November 20, 2010 03:14PM UTC by dmethvin comment:7

#5951 is a duplicate of this ticket.

Changed November 30, 2010 03:05AM UTC by David Sanders comment:8

If you compare jQuery's behaviour with raw JavaScript the results are opposite.

The best policy here is to fix this in the next major version of jQuery and tell people there's a BC break otherwise everyone will have to put up with annoying workarounds until the end of time.

Changed February 17, 2011 04:10PM UTC by anonymous comment:9

Hey,

I was having the same issue, and found a great answer on Stack Overflow here:

http://stackoverflow.com/questions/3478267/jquery-strange-behaviour-on-click-from-a-click

Basically, instead of just calling the click() method of the checkbox, you set the attribute "checked" to true or false, which checks or unchecks the box, and then manually call the event handler by using triggerHandler("click"). Here's the code that I used:

Check the box:

$(this).find("input.city_selector_chk").attr('checked', 'true');

$(this).find("input.city_selector_chk").triggerHandler("click");

Uncheck the box:

$(this).find("input.city_selector_chk").attr('checked', ''); $(this).find("input.city_selector_chk").triggerHandler("click");

Hope this helps!

Paul

Changed February 24, 2011 08:04PM UTC by jitter comment:10

#8374 is a duplicate of this ticket.

Changed March 25, 2011 03:49PM UTC by dmethvin comment:11

#8636 is a duplicate of this ticket.

Changed May 11, 2011 12:03AM UTC by anonymous comment:12

I don't understand why this is a won't fix. Manual triggering of event is basically broken with this bug!

Changed October 13, 2011 01:38AM UTC by euan.ritchie@taitradio.com comment:13

Having recently discovered this issue I note that there is different behaviour between different versions of jQuery;

Given a input:checkbox that has both an inline onclick handler and a jQuery bound click handler the value of checked differs according both to how the click is triggered and what version of jQuery is in use.

Actually clicking on the element in the browser changes the checked value before the events are handled.

With jQuery 1.6.2 using $(element).trigger('click') handles the events before the checked value changes.

In jQuery 1.3.2 the behaviour is slightly different as one handler is called before the checked state changes and the other after.

So at least now the behaviour is consistent across handlers and predictable, though I think ought still be fixed. If not in a minor version change then certainly by jQuery 2.0

Changed November 18, 2011 03:14PM UTC by dmethvin comment:14

#10166 is a duplicate of this ticket.

Changed November 18, 2011 03:15PM UTC by dmethvin comment:15

#10005 is a duplicate of this ticket.

Changed November 18, 2011 03:16PM UTC by dmethvin comment:16

#9274 is a duplicate of this ticket.

Changed November 18, 2011 03:17PM UTC by dmethvin comment:17

#8885 is a duplicate of this ticket.

Changed November 18, 2011 03:17PM UTC by dmethvin comment:18

#8796 is a duplicate of this ticket.

Changed November 18, 2011 03:19PM UTC by dmethvin comment:19

#10827 is a duplicate of this ticket.

Changed April 18, 2012 04:11PM UTC by rwaldron comment:20

#11602 is a duplicate of this ticket.

Changed April 18, 2012 04:23PM UTC by anonymous comment:21

As a note to anyone else suffering with this bug, you can work around this problem by wrapping your checkbox's click event handler in setTimeout(function(){ ... }, 1);

Changed July 03, 2012 05:01PM UTC by dmethvin comment:22

#11991 is a duplicate of this ticket.

Changed July 03, 2012 05:05PM UTC by dmethvin comment:23

keywords: click, event, trigger, checkbox, button1.9-discuss

Changed July 06, 2012 09:24PM UTC by derek.rosenzweig@gmail.com comment:24

I too am having issues with this. I dynamically add a new checkbox, and using delegated 'click' handler:

$('div.parent').on('click', 'input[type=checkbox].classname', function() {

if ($(this).is(':checked')) { <--- this shows opposite value when doing $(element).trigger('click');

do stuff

}

});

Changed July 10, 2012 02:03PM UTC by checat comment:25

Just 2 cents.

Ideally jQuery click() and DOM click() should work identically for elements which have DOM click().

Changed July 13, 2012 03:14AM UTC by coreyog@gmail.com comment:26

There have been 13 duplicate bugs posted in the past 3 years indicating many people find it should not be the way it is. Several fixes ranging from setTimeout(..., 1) to setting the checked attribute and calling the triggerHandler have been proposed but these are work arounds to account for a bug, i.e. people aren't accepting this as expected behavior. Checat makes a valid point for why expectations supports the idea that this is a bug. The cause of the problem has been pointed out by dmethvin and it honestly sounds like an easy fix.

Fixing this bug in a new release would only impact those who have legacy code referencing a constantly changing 'newest release'. Those developers should know that a constantly updated library will occasionally not only have changes, but fixes, that would impact their projects.

Changed July 13, 2012 03:15AM UTC by dmethvin comment:27

Suggestions for a fix are welcome. Please submit a patch.

Changed August 23, 2012 03:49PM UTC by dmethvin comment:28

milestone: 1.31.9
priority: minorhigh

Okay, let's try one last time, because this one bothers me too. I think this can be fixed with the 1.7 special event hooks if we assume that click is a DOM event and don't let it flow through the normal jQuery.event.trigger path. This may have negative effects for non-DOM usages however, so it's a question of what breaks when we fix this. See also #12379.

Changed September 27, 2012 01:57PM UTC by gibson042 comment:29

+1, let's give it our best shot.

Changed October 29, 2012 04:31PM UTC by dmethvin comment:30

resolution: wontfix
status: closedreopened

Changed October 29, 2012 04:31PM UTC by dmethvin comment:31

owner: → dmethvin
status: reopenedassigned

Changed November 24, 2012 07:53PM UTC by Dave Methvin comment:32

resolution: → fixed
status: assignedclosed

Fix #3827. Get the correct checkbox status for a click handler.

Changeset: 1fb2f92c357b985a5ba18d0938edd27b5f64d8c3

Changed January 11, 2013 06:03PM UTC by dmethvin comment:33

#13194 is a duplicate of this ticket.