1
0
mirror of synced 2024-11-25 22:36:03 +03:00
select2/tests/unit-jq2.html

100 lines
4.1 KiB
HTML
Raw Normal View History

<!doctype html>
<html>
<head>
<link rel="stylesheet" href="vendor/qunit-1.23.1.css" type="text/css" />
<link rel="stylesheet" href="../../dist/css/select2.css" type="text/css" />
</head>
<body>
<div id="qunit"></div>
<div id="qunit-fixture">
<div class="event-container">
<select></select>
</div>
<select class="single">
<option>One</option>
</select>
<select class="single-empty"></select>
<select class="single-with-placeholder">
<option>placeholder</option>
<option>One</option>
</select>
<select class="multiple" multiple="multiple">
<option>One</option>
<option>Two</option>
</select>
<select class="groups">
<optgroup label="Test">
<option value="one">One</option>
<option value="two">Two</option>
</optgroup>
<optgroup label="Empty"></optgroup>
</select>
<select class="duplicates">
<option value="one">One</option>
<option value="two">Two</option>
<option value="one">Uno</option>
</select>
<select class="duplicates-multi" multiple="multiple">
<option value="one">One</option>
<option value="two">Two</option>
<option value="one">Uno</option>
</select>
2017-10-25 19:25:50 +03:00
<select class="user-defined"></select>
</div>
<script src="vendor/qunit-1.23.1.js" type="text/javascript"></script>
Restore compatibility with data-* attributes in jQuery 2.x (#5486) * 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
2019-04-28 05:20:56 +03:00
<script src="vendor/jquery-2.2.4.js" type="text/javascript"></script>
<script src="../dist/js/select2.full.js" type="text/javascript"></script>
<script src="helpers.js" type="text/javascript"></script>
<script src="a11y/selection-tests.js" type="text/javascript"></script>
<script src="a11y/search-tests.js" type="text/javascript"></script>
<script src="data/array-tests.js" type="text/javascript"></script>
<script src="data/base-tests.js" type="text/javascript"></script>
<script src="data/inputData-tests.js" type="text/javascript"></script>
<script src="data/select-tests.js" type="text/javascript"></script>
<script src="data/tags-tests.js" type="text/javascript"></script>
2015-08-22 01:32:10 +03:00
<script src="data/tokenizer-tests.js" type="text/javascript"></script>
<script src="data/maximumInputLength-tests.js" type="text/javascript"></script>
<script src="data/maximumSelectionLength-tests.js" type="text/javascript"></script>
<script src="data/minimumInputLength-tests.js" type="text/javascript"></script>
<script src="dropdown/dropdownCss-tests.js" type="text/javascript"></script>
<script src="dropdown/positioning-tests.js" type="text/javascript"></script>
<script src="dropdown/selectOnClose-tests.js" type="text/javascript"></script>
<script src="dropdown/stopPropagation-tests.js" type="text/javascript"></script>
<script src="options/ajax-tests.js" type="text/javascript"></script>
<script src="options/data-tests.js" type="text/javascript"></script>
<script src="options/deprecated-tests.js" type="text/javascript"></script>
<script src="options/translation-tests.js" type="text/javascript"></script>
<script src="options/width-tests.js" type="text/javascript"></script>
<script src="results/focusing-tests.js" type="text/javascript"></script>
<script src="results/infiniteScroll-tests.js" type="text/javascript"></script>
Results respect disabled state of `<option>` (#5560) 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 #3347 Closes #4818
2019-07-10 03:58:13 +03:00
<script src="results/option-tests.js" type="text/javascript"></script>
<script src="selection/allowClear-tests.js" type="text/javascript"></script>
<script src="selection/containerCss-tests.js" type="text/javascript"></script>
<script src="selection/multiple-tests.js" type="text/javascript"></script>
<script src="selection/placeholder-tests.js" type="text/javascript"></script>
<script src="selection/search-tests.js" type="text/javascript"></script>
<script src="selection/single-tests.js" type="text/javascript"></script>
<script src="selection/stopPropagation-tests.js" type="text/javascript"></script>
<script src="utils/decorator-tests.js" type="text/javascript"></script>
<script src="utils/escapeMarkup-tests.js" type="text/javascript"></script>
</body>
</html>