Focus and blur are miserably quirky in IE all the way up to IE10. We've discussed the issues with the IE team and they plan to look at it, but in the meantime I think there is very little we can do to rectify this from within jQuery.

I tried to deal with several of these issues such as #6705 during the 1.7 era but couldn't find an acceptable solution. Better to have it fire twice than not to fire at all--even though that's EXACTLY what the native handler does when the element already has focus.

Duplicate of #6705.

Erm… I'm sorry but did you actually read the bug or did you just read the title, assume it was an IE bug and tag it? The IE-fires-twice issue is a minor side-note, the bigger issue and the one after which the report is titled is that jquery fires the blur and focus events ''in the wrong order'' when programmatically focusing a field, that's got nothing to do with IE, it happens this way in every single browser I tested.

Well I thought I read the bug, but I must have missed an important plot point around chapter 12.

So if I may do Cliff Notes here, you are saying:

• **DOM:** A.focus() with B in focus fires blur-B, focus-A.
• **jQuery:** $A.focus() with B in focus fires focus-A, blur-B.

Except in IE, where it's more complicated. Is that right?

And, although it wasn't stated, jQuery's behavior has been like this ever since version 1.1 or so.

DOM: A.focus() with B in focus fires blur-B, focus-A.

and so will user-generated (non-programmatic) focus changes, yes.

jQuery: $A.focus() with B in focus fires focus-A, blur-B.

Yes, with the consequence of breaking a widespread pattern for handling focus within a group of fields.

And, although it wasn't stated, jQuery's behavior has been like this ever since version 1.1 or so.

I only tested 1.6 and 1.7, but wouldn't be surprised if it were older, so I'll trust you on that.

The break/fix is in the exact same place as the one I marked a dup, it's here:

https://github.com/jquery/jquery/commit/6a670df9e9b9e5cd278b390a2e99ac179307a4e9#L0R527

The idea was to try and use the native method to get similar behavior, but we can't do that easily because of delegation issues, IE focus inconsistencies, and problems with already-focused elements not firing focus.

Again, a patch is welcome, but it will still require handling all the special cases where people expect handlers to fire when they natively don't. I wasn't able to figure out a bulletproof solution when I was working on that code.

The workaround short of a patch is to fire DOM focus manually (e.g., $(el)[0].focus() instead of $(el).focus() and deal with its quirks instead of jQuery's quirks.

The workaround short of a patch is to fire DOM focus manually

Sure, and that's how we fixed it, but it's rather frustrating to look for fuck-ups in your code, and end up realizing select's broken after all, in a way which diverges from all native behavior.

edit: although

The idea was to try and use the native method to get similar behavior, but we can't do that easily because of delegation issues

for focus/blur, does that not happen just when the events are delegated? We're using direct binding — as in the demo case I posted — so the events ''should'' go through native should they not? Would the issue not be with the morphing-on-trigger, which converts the native events and blows up the ordering, rather than with the change you link to?

The source is there if you'd like to make suggestions. Maybe you could solve the problem. I've explained why we can't do EXACTLY what the native method does, it's not what people expect to happen. They want their focus/blur handler to fire when they trigger an event, regardless of whether the element is in focus/blur at the moment.