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.
This fixes an issue when using a `<select>` where the elements were
created with XHTML-encoded characters to prevent any injection, as
they would be double-encoded and display incorrectly.
When using a `<select>`, we can assume that the data has already
been encoded because any XSS will have already run before we get to
it. Because of this, we can just use `.text()` instead of `.html()`
to avoid any issues.
This also includes a test to ensure that this does not become an
issue in the future.
This closes https://github.com/select2/select2/issues/3115.
This fixes the fallback path for the `data-ajax-url` attribute on
elements. As this attribute was previously supported in Select2,
the attribute has been migrated to the new, nested format of the
url and triggers a deprecation warning when it is used. Because
of a fix to the `data-*` attribute parsing made in a9f6d64 that
allowed for nested attributes to be parsed correctly in modern
browsers under jQuery 1.x, the deprecation warning would be
triggered but the attribute would no longer actually be used.
This also fixes some of the `.data` calls to use the camel cased
version of the key instead of the dashed version, which is the
preferred key and will be enforced in future versions of jQuery
as the only way to access data attributes.
Now in situations where the `dataset` attribute is used by Select2,
it combines the results of both `$e.data()` and `e.dataset` when
generating the object containing all of the options. This will
the `dataset` fix to still be used, while also still relying on
jQuery to do additional parsing on any options that it can.
The `dataset` fix is now only used on jQuery 1.x, as that is the
only version of jQuery affected by the dash issue. This is done
using version number parsing on the `$.fn.jquery` property that is
defined by jQuery. As this property is not defined in Zepto and
many other jQuery compatible checks, we only include the fallback
if the property is available. This assumes that any jQuery
compatible libraries that are in use will not include the same dash
issue, which we believe is a safe assumption given that it did not
match the HTML `dataset` specification.
This also adds a few tests to ensure that the deprecated attributes
still continue to function.
This closes https://github.com/select2/select2/issues/3086.
Previously Select2 would assume that the tab index for the
`<select>` was `0`, which is the browser default. Now Select2 will
clone the tab index from the original element, and correctly restore
it when it is destroyed or disabled/enabled.
This closes https://github.com/select2/select2/issues/3031.
This groups tests into common HTML files so they can be run more
quickly. This also reduces the number of Sauce Labs instances that
have to be run, as one instance was previously spun up for each
file.
This sets up Select2 to be able to run tests on the SauceLabs
environment. This will allow us to run the tests on different
browsers in the future, though at the moment we need to start
combining test files.
This required adding a snippet of code for reporting QUnit test
results to SauceLabs within the global test helper file.
The tests currently cannot be run on IE 8 because all of the tests
are using jQuery 2.x, which is not compatible.
This adds `StopPropagation` modules that will stop the propagation
of the most common events from the selection and dropdown containers.
These modules work from a list of 21 common events, most of which
were stopped by default in past versions, and call `stopPropagation`
on them when they are detected at the container level.
These modules are only available in full builds of Select2.
This closes https://github.com/select2/select2/issues/2033.
This closes https://github.com/select2/select2/issues/2974.
The search box previously displayed a clear icon on the far right
side in webkit-based browsers, specifically Chrome and Safari. This
hides the clear icon in those browsers, and also fixes a slight
sizing issue, so it should no longer be displayed.
This also disables autocorrect, autocompleted, as well as a few
other automatic search corrections on the field, so mobile devices
should have a better experience.
This closes https://github.com/select2/select2/issues/3018.
It is assumed that DOM elements or related objects will have been
escaped before they are passed back from templating functions. As
strings are typically blinding concatenated, like in our defaults,
it makes sense to escape the markup within them.
This is related to https://github.com/select2/select2/issues/3005.
