Remove 100ms lag on blur by using custom blur and focus events.

[adunkman]

@harvesthq/chosen-developers /cc @jisraelsen

This PR changes the way focus tracking occurs, relying on focusin and focusout events on the Chosen container instead of focus and blur events on the search input itself. The key benefit is that when the search input is blurred in the process of clicking on a search result item, focus is still maintained within the Chosen container. This allows us to drop our mouse_on_container tracking as well as the 100ms-delayed blur_test.

For a quick review of the events used here:

	focus	focusin	blur	focusout
When?	When an element is focused.	When an element is focused.	When an element is blurred.	When an element is blurred.
Where?	Triggered on the element which is focused and does not bubble up the DOM.	Triggered on the element which is focused and every element which contains it (it bubbles up the DOM).	Triggered on the element which is focused and does not bubble up the DOM.	Triggered on the element which is focused and every element which contains it (it bubbles up the DOM).

I’ll drop a few inline notes to explain more!

[tjschuck]

@adunkman Just to double check: this just removes some extra extraneous focus on some unexpected element, right? Chosen currently styles properly on focus like you'd expect (good for accessibility!), so I'm hoping this is just that!

[adunkman]

Correct! This removes a focus rectangle around the Chosen DIV itself, which only occurs when clicking on search results (after the search input has blurred but before the search result is selected). It’s a side effect of adding tabIndex — it’s quite jarring, since it’s an unexpected element to receive focus in this case.

[adunkman]

When attempting to click on an item in the Chosen drop but missing by a pixel or two, we don’t want the Chosen drop to close. We can add a tab index, which allows it to receive focus — resulting in the following:

0. The search input has focus, and the user attempts to use their mouse to click on a result.
1. The user begins clicking. The search input blurs, triggering a focusout event, which is caught on the container and a setTimeout is scheduled.
2. The container receives the mouse event, which focuses the container. The container triggers a focusin event, which is caught on the container and nothing happens (@active_field is true).
3. The setTimeout expires, checking to see if the container contains document.activeElement, which is in this case, itself. As defined in the spec, a Node .contains() itself, and therefore the drop is not closed.

[adunkman]

I think relying on custom events here (chosen:blur and chosen:focus) are the most straightforward way to handle this — but we can also just simply inline the calls to input_focus and close_field in the container_focusin and container_focusout events below. Let me know which you prefer!

[koenpunt]

This suggests that those events can/should be invoked from a client implementation, which I think is not the case, right? So I think inlining them below would be better.

[adunkman]

Since we now only trigger our chosen:focus and chosen:blur events when focus is lost on the entire container or its descendants, we no longer need to track mouse positioning.

[koenpunt]

Looks promising, but does is work cross browser?

[koenpunt]

Also, how does it behave when having focus in the input and then pressing tab? Especially in the case when the cursor is still positioned over the Chosen select. Because I can imagine that the focusout event might not be triggered then.