In the previous commit (02cca7b) support was added for multiple
selects to automatically focus when they were tabbed into. While
this did actually work, it caused a few bugs with the focus that
prevented users from tabbing out of the container, effectively
trapping keyboard users in Select2.
This makes a few major changes to how things work in Select2, but
should not break any backwards compatibility.
- The internal `focus` event is now proxied through a `focus`
method on the core object. This allows for two important things
1. The `focus` event will only be triggered if Select2 was in an
unfocused state.
2. Select2 now (unofficially) supports the `select2('focus')`
method again.
But that does mean that it is possible to trigger the `focus`
event now and not have it propagate throughout the widget. As
it would previously trigger multiple times, even when Select2
had not actually lost focus, this is considered a fix to a bug
instead of a breaking change.
- The internal `blur` event in selections is only triggered when
the focus is moved off of all elements within the selection. This
allows for better tracking of where the focus is within Select2,
but as a result of the asynchronous approach it does mean that the
`blur` event is not necessarily synchronous and may be more
difficult to trace.
- On multiple selects, the standard selection container is never
visually focused. Instead, the focus is always shifted over to
the search box when it is requested. The tab index of the selection
container is also always copied to the search box, so the search
will always be in the tab order instead of the selection container.
It's important to note that these changes to the tab order and how
the focus is shifted do not apply to multiple selects that do not
have a search box. Those changes also do not apply to single select
boxes, which will still have the same focus and tabbing behaviours
as they previously did.
79cdcc0956