This behaviour, where the focus was happening on a small asynchronous
delay, was added in commit 933189b92 late last year in a commit with
no supporting tickets or commit message explaining what the change
was trying to accomplish. This commit has effectly been reverted within
this commit, since it caused a regression in how focus was being
assigned that made it inconsistent with a standard `<select>`.
A test was added for this which ensures that we won't see that
regression again.
Fixes#5532Fixes#5185Closes#5552
Ever since the 4.0.0 release of Select2, there has been a bug where
if you enabled infinite scrolling but did not return enough results
on the first load of AJAX to show a scrollbar, then infinite
scrolling would not be enabled and you could not view anything other
than the first page of results. The solution for this was first
proposed in #3888 but it was closed off because of inactivity and
missing tests.
This fixes the issue by performing the check to see if more results
should be loaded both on scroll and also when the results are first
loaded. This solves the issue that we were seeing before, because
the plugin knows it needs to load in more results, just it did not
receive the scroll event before and thus was not able to actually
load in the new results.
This has the potential to trigger multiple AJAX requests to load in
multiple pages of results if the user has the ability to see many
options, but only a few are being loaded at a time.
This also adds tests for infinite scrolling, both to ensure that
it will attempt to load additional pages, even without the scrollbar,
and to ensure that the regular behaviour of not loading additional
pages when the scrollbar is visible is preserved.
Fixes#3088
This check is in place in most other places, mostly because we have
run into widespread issues under similar circumstances and we like to
avoid those, but it was forgotten here. There also were no tests
covering this, so it was never caught.
This adds tests that ensure that the option in the results list will
be generated with the correct "disabled" state based on whether or
not it, or a parent element, is marked as disabled.
This should have been easy: just check `element.disabled`
Unfortunately the `disabled` property is not inherited within the
option chain, so if an `<optgroup>` is disabled, the `<option>`
elements or other `<optgroup>` elements held within it do not have
their `disabled` property set to `true`. As a result, we needed to
use the `matches` method to check if the `:disabled` state is
present for the element. The `matches` method is part of the official
standard, but it was not implemented under that name for a while and
as a result Internet Explorer only supports it under the prefixed
`msMatchesSelector` method and older versions of Webkit have it
implemented as `webkitMatchesSelector`. But once we use this method,
it appears to consistently return the expected results.
This `matches` method and prefixed predecessors are not supported in
IE 8, but they are supported in IE 9 and any browsers newer than
that. Instead of buulding a very hacky solution using
`querySelectorAll` that was brittle, I have chosen to act like
everyone else and pretend IE 8 no longer exists.
Fixes#3347Closes#4818
* Update tests to be compatible with jQuery 3.0.0
There was a change in jQuery 3 that ensures that the return value of `.val()` on a multiple select is always an array. This is a breaking change from previous versions, where `null` or `undefined` were returned in these scenarios. Because we cannot `assert.equal` on a list of possible values, these assertions were switched to `assert.ok` which should be good enough.
* Properly strip out units in positioning tests
Before we were assuming that there were no units, and only were we stripping them out if we were expecting 3 digits. Now we just strip out all non-digit characters, so that should do the job and get us what we want.
There was a change in jQuery 3.2.0 that caused the units to be returned in these specific calls. They were not previously being returned, so this was not actually an issue.
* Add automated testing against jQuery 3.4.1
No tests appear to be currently failing.
