Skip to main content

Bug Tracker

Side navigation

#13919 closed bug (wontfix)

Opened May 22, 2013 06:45AM UTC

Closed June 12, 2013 08:51PM UTC

Last modified June 17, 2013 01:46PM UTC

Synthetic click events on unattached checkbox doesn't trigger event delegate

Reported by: Morgan Roderick <> Owned by:
Priority: low Milestone: None
Component: event Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:

In jQuery 1.7.2, it is possible to trigger an event delegate when firing synthetic click events on checkboxes that are not attached to the document. In 1.9.x it is not.

I've created a reduced test case to show this behaviour:

Please note that it's only reproducible in WebKit based browsers, but it has been reproducible in all the WebKit based browsers I've tried.

Attachments (0)
Change History (9)

Changed May 22, 2013 09:02PM UTC by dmethvin comment:1

owner: → Morgan Roderick <>
status: newpending

Is there a compelling use case for this? We can go back to using a totally synthetic click event for checkboxes but it will mean we have to reopen several tickets related to focus and event order.

Changed May 22, 2013 11:02PM UTC by mrgnrdrck comment:2

I discovered this behaviour by having a lot of test cases fail unexpectedly, while preparing to upgrade from 1.7.2 to 1.9.1. The tests are run in PhantomJS (WebKit based) during CI builds, and were failing there, as well as in Chrome during development. It is often easier to work with unattached nodes, as cleanup is usually easier, when you don't need to reset the document between tests, just release one node.

What I don't quite understand is that this behaviour only happens in WebKit based browsers. Could it be a bug in WebKit? Or is it merely a case of WebKit having a different interpretation of a standard? Also, why is this specific to checkboxes?

(The relevant code in jQuery was not obvious to me)

Changed May 22, 2013 11:57PM UTC by dmethvin comment:3

owner: Morgan Roderick <>
status: pendingnew

I suspect that WebKit doesn't want to trigger UI events natively on elements that couldn't possibly be clicked since they're not in a document. Probably has something to do with their internal design. To make your unit tests more realistic I'd attach the elements to the document, it's better to get a native event than a fake one.

Changed May 23, 2013 12:45AM UTC by gibson042 comment:4

_comment0: This might be another one resolved by the eventual pluginization of [] (volunteers welcome ;), but it's just such a tough nut to crack in core.1369270003896728

This might be another one resolved by the eventual pluginization of the #13353 work (volunteers welcome ;), but it's just such a tough nut to crack in core.

Changed June 12, 2013 08:51PM UTC by timmywil comment:5

component: unfiledevent
priority: undecidedlow
resolution: → wontfix
status: newclosed

Seems like this can be closed as more follow-up would mean regressions elsewhere. Please reopen if there are objections.

Changed June 13, 2013 07:11AM UTC by mrgnrdrck comment:6

I DO object!

This is a regression made by the refactorings of how synthetic events are being handled (the click event on checkboxes is the only exception, that get's a regular event).

jQuery markets itself as being cross-browser, it's even got a spinning logo for that on the frontpage of

Sadly, I can't seem to re-open this ticket with Trac

Changed June 13, 2013 02:30PM UTC by dmethvin comment:7

Can you suggest a fix then?

Changed June 17, 2013 08:06AM UTC by mrgnrdrck comment:8

Replying to [comment:7 dmethvin]:

Can you suggest a fix then?

Well, I can, but it's unlikely to be as good as a suggestion from the people who refactored the event internals between 1.7.x and 1.9.x. For one thing, you can't read motivation or history out of the source code and (luckily) there's not comments with ticket numbers for every line.

Any suggestion I am going to be able to provide, is most likely to fall into the category of "we already discussed that" or "it's a design decision", since I don't have the whole history of that refactoring in my head.

Perhaps it would be better to ask Richard Gibson, who wrote the checkbox specific code with commit 14b09ef9 (at least according to git blame), if he has any suggestions on how to fix this.

Changed June 17, 2013 01:46PM UTC by gibson042 comment:9

Yours truly has already weighed in on this and related tickets like #13353. The commit you reference was part of a series (also including 14c50da7 and 65a66489) put in place specifically to create hooks so they can be patched via plugin.

The root problem, for which a satisfactory solution has not been found, is that the checkbox checked state visible to event listeners is wrong unless we rely upon native events for our entry point.