This prevents selections from being removed when the container is
disabled. This stops any click events that are triggered on the
remove button, so the remove handler won't be triggered at all.
This closes https://github.com/select2/select2/pull/3636.
These tests should fail because a selection can be removed even
though the container is disabled. This is because the only thing
preventing selections from being removed was the CSS which hid the
remove buttons when the container was disabled.
Right now Sauce Labs is not triggering builds for Firefox, and that
is causing the automated testing to fail. This might be because
there is no "latest" version logged for Firefox on Sauce Labs, but
it could also be becuase we aren't giving it a platform to look for.
This was also done for Opera as right now Sauce Labs is running
tests on Linux anyway.
This adds the test that ensures that the search focus is still
focused, even after the selection is updated (for whatever reason).
Note that we are not triggering the `change` event here, and are
instead just re-calling `update` on the selection adapter. This is
because we do not bind the `change` event in tests, so the selection
is never re-rendered and the tests will pass. The `update` method
is triggered during the `change` cycle anyway, so this has the
same effect while supporting cases where the selection is re-rendered
without the selected values changing.
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.
