- updated transaltions
- added translation for errorLoading
- issue fixes - compare characters length instead of message when adding terminal character
This closes https://github.com/select2/select2/pull/4208
The issue template is largely based on the questions included in the
canned comment that I use for bugs, which is mostly covered in the
contributing guide. Even though there are a lot of lines, most of it is
just ticking checkboxes.
The issue template is focused on bug reports, as those are considerably
more common than feature requests.
The pull request template was designed to be pretty slim, we haven't had
many issues with these in the past.
This fixes some bugs that were present in the old Prettify highlighter
when there was a mix of JavaScript and HTML in the same code block. Now
with Rouge, the highlighter used by Jekyll, these cases are properly
handled and HTML no longer looks strange.
This does not convert all of the code blocks over, because there are
still some code blocks which double as the actual JavaScript code
powering the example that need to be migrated.
We previously used Google's Prettify, which worked on the client side.
Now that we are actually using Jekyll, and it has built-in syntax
highlighting, we might as well change to doing highlighting on the
backend.
Use of protocol-relative URLs is now seen as an anti-pattern as it leaves the door open to attacks. As the CDNs serve over HTTPS it should be recommended that people use HTTPS rather than protocol-relative URLs. See Paul Irish's post on [Protocol-relative URLs](http://www.paulirish.com/2010/the-protocol-relative-url/) for more details.
This adds more code examples where they might be useful, and adds some
more description where it was needed. This clarifies a couple of the
questions that have come up about the AMD support and links to the bug
that Select2 was involved with that some people reported when 4.0.0 was
released.
This display the `errorLoading` translation when there is an error
during the AJAX cycle. Previously we were just throwing these errors
out, now we are actually displaying an error message.
This closes https://github.com/select2/select2/issues/3501
This fixes the documentation so the responsive example actually works.
Everything was working properly, the example just wasn't updated when
the default for the width was changed to `100%` in
5fd72d2052.
This is a change from the old `resolve` width setting, which is
responsible for parsing the style attribute and getting the width that
was set.
This closes https://github.com/select2/select2/issues/4050
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.
