In order to enable the ability to uniquely identify a result by an ID
in the DOM, we generate a new ID for the result based on a combination
of things, including the container ID prefix that is generated and
used elsewhere in Select2. This has worked fairly well for use cases
including attaching Select2 to an existing `<select>` and loading in
options from a remote data set.
Unfortunately, because this process relied on the container ID being
used as a prefix, this failed for options which were automatically
generated on initialization using the `data:` option to Select2.
These were not being generated with an ID because at the time that
they were being generated, the data adapter was not aware of the
container it was being used in. This broke some accessibility features
because we had a mix of options in the results list with IDs, and
some without, so we fixed the ordering to make this work.
Option generation no longer happens when the data adapter is first
initialized, which is where it was previously happening, and instead
it now occurs when the data adapter is bound to the container. This
allows us to ensure that the data adapter is always aware of the
container it is being associated with, so now it will be able to
generate the result IDs.
This also fixes the tests for the array adapter as well as the
legacy `<input />` adapter so they properly bind to a container
during the test. This was causing test failures becuase the options
which would previously be generated during initialization were no
longer appearing.
Fixes#4350
* Rewrote maximumSelectionLength tests to use container
These brings the tests in line with other tests which we have, and
makes it easier to understand what is actually going on in the tests.
This also removes a redundant set of tests where we were testing with
=> 2 options being allowed. There are no current edge cases that would
have required this.
* Fix maximumSelectionLength being ignored by closeOnSelect
There was a bug where the `maximumSelectionLength` option would not
kick in if the `closeOnSelect` option was enabled. Normally, this
was enabled by someone in their global configuration, but it could
also be seen when somoene selected an option while holding the
meta/ctrl/alt keys. This would implicitly enable the `closeOnSelect`
behaviour, even when it was not globally enabled, and cause the bug.
This fixes that issue by listening to the `select` event which is
triggered whenever an option is selected, and triggers the "maximum
selected" message based on that event. This should now force the
message to be displayed, even when the results did not have to be
queried another time.
Fixes#3514Fixes#3860Closes#5333
This fixes a long-standing bug where if you tried to click in the
search box for a multiple select while there was text in it, the
dropdown would close and the text would be cleared. This caused
many unexpected issues, because it meant that you could only use
your keyboard to edit text within the search box.
This will still clear out the search field if you click within the
area of the selection which is not the search field. I'm not sure
if that is also unexpected behaviour, so for now I am going to
maintain it.
Fixes#3517Fixes#3808Fixes#5491Closes#5551
This is needed to screen readers know that the Select2 is disabled
when focus is put on the selection container. Because we were
mirroring the disabled state to the search input on a multiple
select in the past, this is really only needed for single select
elements which would not otherwise has the disabled property.
This was identified in a previous accessibility audit as being
something which Select2 did not properly report because we were
not setting the attributes properly.
Fixes#4575
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
This allows for more accurate resolution of the width when compared
to the `resolve` method. This is more relevant for jQuery 1.x, where
the `resolve` method cannot find the width of a hidden select box,
but it also applies to newer versions of jQuery where the `width()`
method provided by jQuery doesn't fully match `getComputedStyle()`.
Fixes#3278Fixes#5502Closes#5259
* Add test for losing focus when searching tag entries
* Revert unknown unit test fix
Removing this no longer breaks a unit test, and having it in here
results in the select box receiving focus unexpectedly. It's not
clear what problem this was solving, since it was manually applied
from a series of pull requests.
It claims to be fixing an issue that was specific to IE11, and I'm
willing to re-introduce that bug because there doesn't appear to be
a regression test for it, and it's breaking some critical use cases.
The goal should be to focus the search box if it would have normally
lost focus when the selection was updated.
Fixes#5485Fixes#5516Closes#5550
* 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.
We needed to define the `qunit` module in the unit tests because there was a change in grunt-contrib-qunit 0.6.0 that breaks when you define an AMD loader. It expects that the AMD loader is also used to load QUnit, instead of just being used to support the tests, so if you don't define the qunit module it will just hang and do nothing. Luckily we have the helpers file to help us out here, since it allows us to globally define this module.
* Start running tests against jQuery 2.x
We were only running tests against jQuery 1.x before and they were
all passing. This was a problem because apparently all of the data-*
attribute tests fail in jQuery 2.x. We are now running both the
integration and unit tests against both jQuery 1.x and jQuery 2.x.
Right now this resulted in a complete duplication of the test files
because there wasn't an obvious way to run the tests against both
versions. We're going to look into removing this duplication in the
future once the current issues are fixed.
We are also going to look into testing against jQuery 3.x in the
future, since that is also a supported line of jQuery.
* Force the data-* attributes to be parsed
There was a change made that switched us from using `$.data` and
`$.fn.data` internally to using an internal data store (managed
through internal utilities). This had the unfortunate side effect
of breaking the automatic loading of data-* options in versions of
jQuery other than 1.x, which included anything that would be
considered modern jQuery. While the change was made and approved
in good faith, all of the tests passed and the docs pages appeared
to be working, the tests really failed when running on newer versions
of jQuery. This was confirmed when we started running automated tests
against both versions, which confirmed the bug that others have been
seeing for a while.
The change was made becuase calling `$.fn.data` on an element which
contains a reference to itself in the internal jQuery data cache
would cause a stack overflow. This bug was well documented at the
following GitHub ticket and was resolved by no longer using
`$.fn.data`: https://github.com/select2/select2/issues/4014
Unfortunately because `$.fn.data` was no longer being called in a
way such that all of the data attributes would be dumped out, we
needed to find a replacement. The substitute that was given in the
original bug fix worked when the data cache was fully primed, but
we never primed it anywhere so it actually failed in the general
case. That meant we needed to find a way to manually prime it,
which is exactly what this change does.
* Clean up select2/utils
* 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.
This was required for us to get assert.async() support within tests, as
well as assert.expect() support. This was required because we need them
for multiple async tests that are coming.
These tests did not cover the classes that should have been
automatically applied to the dropdown based on the space around it. Now
they both test that the dropdown should be facing down, because there is
enough space below it to display the dropdown.
This adds a broken test that demonstrates the issue seen in
https://github.com/select2/select2/issues/3990 where existing selected
options are being reset once Select2 is initialized. This issue cannot
be reproduced on the options page [1] because the issue only appear to
happen if the selected option is not the first one in the list of
possible options.
[1]: https://select2.github.io/examples.html#data-array
This fixes the two failing assertions that only triggered in IE 9 (no
other versions) and Firefox. Both of them were caused by the offset for
the dropdown including a constant extra amount, what appeared to be
related to the size of the container if it actually had content. This
was not consistent in browsers, so now we are forcing there to be a
small amount of content within the container and then calculating the
expected offset based on that height.
There was a commit that landed in 4.0.1 that fixed positioning for
non-static elements, which are commonly used for the custom
`dropdownParent` option, but broke positioning for statically positioned
elements, commonly used in almost every other case. That commit was
c9216b4b96
This fixes the positioning issues caused by that commit by properly
calculating the offsets for statically positioned parents. Statically
positioned parents are unique, because the offset for the dropdown must
be calculated based on the closest element that is non-statically
positioned. Otherwise, the offset for any statically positioned parent
other than the body will be considerably higher than it should be,
resulting in the dropdown being offset by a large amount.
The offset parent for the body element is the html element, which is why
this works for both the body element and any custom parents for the
dropdown. This would not be needed if the parent wasn't customizable (as
seen in Select2 3.x) because you will never need to offset the body
element if it is statically positioned, because the html element almost
never has an offset.
This also fixes JSHint issues within the tests added in the last commit.
This closes https://github.com/select2/select2/issues/3970
This closes https://github.com/select2/select2/issues/3639
This adds a regression test that verifies the problem with positioning
the dropdown when the parent is a statically positioned element that
still has an offset. This could typically be seen if the body element
has an offset, which unfortunately it almost always does because of the
default user stylesheet in browsers. This was not caught during
pre-release testing because all of the test pages reset the margins and
padding on the body element.
This regression test verifies that the offsets that should be set for
the dropdown are calculated correctly. These were surprisingly difficult
to do because of how the offset is calculated using different
positioning techniques.
These tests are for https://github.com/select2/select2/issues/3970
