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.

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)

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.

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.

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

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 jquery.com.

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

Can you suggest a fix then?

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.

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.