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
* 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
To match last standards, see [CSS hide and seek](http://hugogiraudel.com/2016/10/13/css-hide-and-seek/) for more explanations :)
Also I removed the negative margin because of unwanted effects in some case, as seen on Bootstrap.
See #3895, and jQuery docs on `attr`:
> As of jQuery 1.6, the .prop() method provides a way to explicitly retrieve property values, while .attr() retrieves attributes.
