This fixes an edge case that occurred pretty much whenever anyone would
use array data with existing selections along with a placeholder. This
caused the existing selections to be discarded, because the `selected`
property was not being transferred over to the new option. This was
based the new data was being preferred over the data that could be
inferred from the option, and the new data typically did not include the
selected state. As a result, the option was assumed to not be selected.
This was not cause by existing tests because all of the existing tests
only covered cases where the selected option was the first option, and
that was not affected by this bug.
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.
This call to `$.fn.position` was causing an error in IE 8 because the
`offsetParent` was null on the container for some reason. It's not
needed, so this line of code has been removed.
This should fix the test failures in IE 8.
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
This fixes an infinite loop that used to be caused when both
`closeOnSelect` and `selectOnClose` used to be combined, because they
both were listening to events triggered by the other one. The problem
was that `selectOnClose` was triggering `select` events for data objects
which had already been selected. This problem was solved by checking if
the data object was already selected before trying to select it again.
This closes https://github.com/select2/select2/pull/3751.
This closes https://github.com/select2/select2/issues/3169.
This changes the Grunt script to automatically pull the locations of the
NPM versions of the Almond loader and jQuery mousewheel plugin. This
means we no longer need to include these vendor files in our repository,
as the builds will automatically pull from the existing NPM files.
These are technically only required when building the final versions,
but if someone is pulling from NPM they may want to deal with building
it as well. Almond is used for loading in packages and jQuery Mousewheel
is used to prevent the results from scrolling the page.
In
f1e86470ca
we tried to fix the issue where multiple instances created in a single
call would share the same options, and this worked for the most common
cases. Unfortunately it did not work for the case where data attributes
were also used with an options object, and as a result data attributes
would be copied to all instances. Data attributes are supposed to be
specific to a single instance.
This was fixed by moving the `true` for the deep copy to the start of
the `$.extend` call, as this is where jQuery looks for the deep copy
flag.
This closes https://github.com/select2/select2/issues/3485
This fixes a previous bug with the backspace handler on the multiple
select search box where unselecting a choice through the keyboard would
not properly size the search box. As a result, most of the text would be
cut off and it was very clear that there was an issue.
In addition, a blank space was automatically being added to the end of
the search query. This blank space would not be removed at all, so the
user had to manually remove it.
Additionally, a query would be triggered for the last used search term
instead of the new search term that would be loaded in. This caused
incorrect results to be displayed most of the time.
All of these issues have been fixed by triggering a new search query
after an option has been removed through the keyboard. This will resize
the search box automatically, which fixes the main issue, and it will
trigger a search with the correct query.
This closes https://github.com/select2/select2/issues/3297
This closes https://github.com/select2/select2/pull/3398
This fixes an issue when any of Select2's special options are called on
multiple elements, it would only affect the first option in the group.
This was because Select2 was only applying any changes to the first
element in the group (as chosen by jQuery) instead of applying changes
on each and every element within the list.
This has the new side effect of special options like `select2('data')`
returning the results for the last element in the list instead of the
first element. Because the previous functionality was considered
unspecified behaviour, this is not being treated as a breaking change.
This closes https://github.com/select2/select2/issues/3413
This closes https://github.com/select2/select2/pull/3495
This will now pass all of the AJAX parameters into the AJAX request as
query string parameters, so now the page number (and other variables)
will be set automatically. This can still be overridden in `ajax.data`
to pass anything else, but this should make it easier for the most
common case.
This closes https://github.com/select2/select2/issues/3548
This closes https://github.com/select2/select2/pull/3552
This fixes an issue where the old `option` and `load-more` classes were
not switched over to the newer BEM style of class names. Unfortunately
this is a breaking change, but this is also a bug given that it doesn't
follow the proper prefixing and is likely to conflict with larger
applications.
https://github.com/select2/select2/issues/3889
Previously `this` would point to the AjaxAdapter that was being used to
process the AJAX, or sometimes the JS object holding the AJAX options,
instead of the jQuery element that Select2 was attached to. This fixes
the issue so `this` will consistently point to the jQuery element, just
like in past versions of Select2.
This closes https://github.com/select2/select2/issues/3361
This closes https://github.com/select2/select2/pull/3410
About `errorLoading`:
Before the correction, the translation was: "התוצאות לא נטענו בהלכה".
The word "בהלכה" is wrong and should be spelled "כהלכה", but besides that, this translations means "The results were loaded improperly", while my corrected translation means "Error while loading results", which is what needed.
About `inputTooLong`, `inputTooShort`, `maximumSelected`:
In Hebrew, it's not acceptable to have the digit 1 for representing a single object. You should use the actual word "one", which is "אחד" in Hebrew together with the singular noun (e.g. "one item" / "one character", instead of "1 item" / "1 character").
**These 3 parts needed a critical fix anyway**, because they were addind the English letter 's' to the end of the Hebrew string.
About `loadingMore`:
The translation was "טען תוצאות נוספות" which means "Load more results", as an instruction, probably a typo.
I changed "טען" to "טוען" so now it means "loading more results", which is the correct form.
This closes https://github.com/select2/select2/pull/3911
Previously we were only disabling the `input` handler when it was
triggered, which caused a race condition within the `keyup` handlers
which also was triggered by the `input` event. This fixes the issue by
also unbinding the `input` handlers within the `keyup` handler, to avoid
running into the race condition.
Thanks to @Eckankar for pointing out the race condition that still
existed in
66ae2ad1d5
This closes https://github.com/select2/select2/issues/3300
