* Move search accessibility tests under selection tests
* Set aria-activedescendent and aria-owns on selection search
This is a reduced version of a5ab08b49cb which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the selection container. This is the search
box used within a multiple select, and previously it did not always
set these two attributes correctly.
One major change here is that we clear the `aria-activedescendent`
attribute if the result that is selected does not have an ID. This
was not being done previously, instead the attribute was still
containing the old value, and it meant that sometimes the wrong
result was being pointed to.
The test coverage for this was also expanded to ensure that these
attributes are properly being set.
* Set aria-activedescendent and aria-owns on dropdown search
This is a reduced version of a5ab08b49cb which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the dropdown. This is the search box used
within a single select, and previously it did not set these two
attributes at all. Additionally, it did not set the `aria-autocomplete`
attribute, which is also needed for screen readers to properly read
through the list of results.
There was previously no test coverage for this, so the tests were
largely copied from the tests for selection search.
* Set proper ARIA roles on result elements
When Select2 4.0.0 was originally written, accessibility was tested
using the Orca screen reader and Mozilla Firefox as the browser.
Because a `<select>` box could contain `<optgroup>` elements, which
can further contain additional `<option>` elements, Orca would read
out a `<select>` box as a tree view. Apparently Orca was the only
screen reader to do this, but Select2 maintained this behaviour
because the ARIA spec did not allow grouping elements for the right
roles.
In the ARIA 1.2 spec, an element with the role of `listbox` (which
is the proper one for representing a `<select>` element) can now
contain elements with the role of `group` that can be used for
grouping. This means that now Select2 can switch to use the proper
ARIA roles to better match how most browsers represent the `<select>`
element out of the box.
As a result, instead of the Select2 results list being represented
as a tree containing tree items, it is now represented as a listbox
containing options and groups. Notices will be represented as an
alert, which more closely represents what they were being used for.
This is a reduced version of a5ab08b49cb which is split out to only
fix the `role` attributes on elements within the results list.
* Switch search boxes to have a role of searchbox
I'm pretty sure this is implicit now, but since we used to specify
that the search box had a role of `textbox`, we may as well migrate
that over to specify the role of `searchbox`. This is different
from the original pull request where this role was changes to
`combobox`, but that is because we are working against the ARIA 1.2
spec and the original pull request was working agianst the ARIA 1.0
spec, which required the search box to have that role.
* Set aria-controls instead of aria-owns on search boxes
In ARIA 1.1, there was a switch to use `aria-controls` on the search
box to point to the results list instead of using `aria-owns`. This
is required because the `combobox`, in our case the selection
container, should have the `aria-owns` attribute pointing to the
results list. And because only one elment can own another element,
we must fall back to `aria-controls` to represent that relationship.
The tests have also been adjusted to reflect this new discovery.
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
* Add scrollOnSelect as a configurable option
* default scrollOnSelect to true to avoid modifying existing behaviour
* added tests and default option for scrollAfterSelect
After we upgraded to QUnit 1.23.1, we gained support for
assert.expect(). This allows us to guard against any race conditions
within tests, because now expect() will be linked to the specific test
instead of the current running test.
