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
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.
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.
The old functionality where classes were directly copied to the
container can be done by setting `dropdownCssClass: ':all:'` when
initializing Select2.
This closes https://github.com/select2/select2/issues/2879.
This finally fixes and adds some integration tests to make sure
that `select2('data')` works as we are expecting. This also adds
tests for `select2('val')` and fixes undefined variable issues
that were spotted because of these tests.
We also no longer date stamp distribution builds.
This closes https://github.com/select2/select2/issues/3104.
The nested data attributes are only supported on jQuery 2.x or
browsers which support the `dataset` attributes on DOM elements.
In order to prevent test failures, and because tests cannot yet
be skipped conditionally, we just cut the test early.
As jQuery 1.7.2 is the lowest version of jQuery supported by Select2,
it makes sense to run the tests on it. For the most part, we can
assume that the newer versions of Select2 are backwards compatible
enough such that this isn't an issue.
The recommended version of jQuery to use is the latest though, which
is why the jQuery file is only included in the tests.
This revealed a few issues with our data fallbacks and `.append`
functionality that was introduced in jQuery 1.8.
This strips whitespace in tags by default, so multiple tags cannot
be created with only whitespace as the difference in the id.
A test has been added to ensure that this remains fixed in the future.
This closes https://github.com/select2/select2/issues/3076.
