even in 1.4.2, sequentially calling focus() on a,b,c is not exactly what the browsers do.

1.4.2:

focus a

focusin a

focus b

focusout a

focusin b

focus c

focusout b

focusin c

native (no jquery):

focus a

blur a

focus b

blur b

focus c

this is reproducible both manually (mouse/keyboard) and in code

i believe a proper mix should therefore be

$("#a").focus():

blur document.activeElement

focusout document.activeElement (bubbles)

change document.activeElement (if there was a change)

haschanged document.activeElement (maybe a new bubbling change event)

focus a

focusin a (bubbles)

$("#b").focus():

repeat above

$("#c").focus():

repeat above

this is all logged using $('input').bind('focus blur focusin focusout'), not live() or delegate.

blur() should also work via 1-4. i know that different browsers fire change events before or after blur events, so the change() order might be screwy, but a custom "haschanged" or "changed" should always fire reliably after focusout().

i'm not too familiar with the details of the event dispatcher in jquery. i only know the high level overview of what's done (uniformize events via fix(), live handlers for blur/focus/change done via capture, then focusin/out triggered on e.target)

i'll try to slap a patch together that fires off events in the way i've outlined. also noticed there's a .specialChange there already, will need to dig further. preferably, i'd like to get something consistent into 1.5 final since changes to event dispatch order can be chalked up to a major version bump.

are there any IRC logs relating to discussions of event flow that i can read through instead of trying to make sense of everything through code analysis?

yes, there are numerous issues, just proto. technically if you want to catch focusin/out without delegating a blur/focus at same time...those first-order handlers should be registered capturing on document implicitly during lib init. (i think jq does this already)