1
0
mirror of synced 2024-11-22 04:56:08 +03:00
Commit Graph

2416 Commits

Author SHA1 Message Date
Kevin Brown
d54560f21e
Merge pull request #5613 from select2/release/4.0.9
[Release] 4.0.9
2019-08-21 20:59:42 -04:00
diesl
1a6d4a1ad8 Update de.js (#5604)
Improve German translation
2019-08-21 20:26:55 -04:00
Kevin Brown
4afa7f88a4
The language option now has a clearly defined fallback chain (#5602)
* Made the test suite for translations more complete

There were previously tests for translations within the test suite,
but they only covered a select few problem cases that had previously
been fixed. They did not cover the majority of cases, which makes
changes to how the translation mechanism for Select2 works a bit
more challenging.

So this adds tests for the majority of edge cases around translations,
including how one would expect the fallback chains to work and also
around how defaults interact with the language options. This should
not be considered an exhaustive list of all of the edge cases, but
it should be good enough to refactor the internals and not have to
worry as much.

The one change of note to this test file is that we are now properly
resetting the defaults in between tests. This should fix any issues
that we may have seen where the defaults were not being reset, and
thus tests were not properly isolated and would start to interfere
with each other. This required pulling the module definition down
below the imports, since we need to reference the defaults within
the module definition.

Many of these tests will fail because the translation system is
broken in many small, unrealized ways. The next few commits should
make these pass and fix the issues that we are seeing.

* Consistently resolve the language option

This fixes an issue that we have had for a while where we did not
have a way to consistently take the `language` option from a string,
array, object, or whatever else is specified and resolve it into
`Translation`-compatible objects or strings. Now there is a new
internal `_resolveLanguage` function which is able to take any of
the supported ways of specifying a language and resolve it down into
the supported language chain.

This now means that we can properly resolve the following cases,
and we can do it in a consistent manner.

* When the language is specified as just a string (for example: "en")
* When the language is specified as a string containing a region
  (for example: "en-US")
* When the langugae chian is specified as a list of strings (for
  example: ["es", "en"])
* When the language is specifid as an object containing messages
  (for example, when a user overrides only a subset of messages)
* When the language is specified as a list of strings and objects
  (for example, when a user wants to use a language other than
  English and also wants to ovverride some default messages)
* When the language is not specified at all (the most common case)
* When the language is specified as an empty object (an edge case
  that allows us to skip processing it)

This allows us to consistently produce the language fallback chain
based on the given `language` option, something which we could not
actually do before because we didn't have a consistent chain. This also
means that now the `language` option will consistently be an array
after going through this process, instead of being any number of
types before.

The translation generation currently does not support having objects
and strings mixed as a part of the fallback chain, despite that being
how the default chain has always worked, and as such there are still
failing tests around this.

* Move English to always be at the end of the language chain

This was technically true in most cases in the past, because if a
language chain was manually specified then it would have English
injected into the end of it anyway. This is needed because not all
translations are complete, but we know the English one is, and
Select2 relies on the translation that it uses being complete.

This will result in cases where a user specifies a language but still
receives English translation for some things, which is what users
have historically seen when using partial translations anyway. This
just ensures that there will always be a complete translation that
is being used, so they won't get unexpected errors and will instead
get unexpected English translations.

* Filter out repeated languages in fallback chain

This is mostly being done for performance reasons, since Select2
will not behave any differently when there are duplicates, but it
makes things cleaner when you ask for the fallback chain and it
only contains unique values.

This cannot distinguish between languages specified by name (string)
and languages specified by the contents of their language file
(such as the default, English), but this should generally not be
an issue.

* Convert the language chain into a finalized translation

This extracts the logic for converting parts of the language chain
into the finalized `Translation` objects out into its own method,
with some small fixes for edge cases.

This can now properly convert a language chain containing both
strings and objects into a translation object that contains them
both.

We no longer need to special case the `language` option being an
array since we know that it will be an array once the language
resolution process is completed.

* Switch default translation to be empty

This should have no external effects, but it fixes an interesting
bug where resetting the defaults would not always reset custom
translations. This was because it was possible to modify the
included English translation when you were setting a default for the
language option.

This should not cause any issues because the English translation is
now appended to the end of the language chain when the defaults
are applied, which means that English will continue to exist as the
final fallback.

* Inherited `lang` attribute should be below the default in the chain

It was pointed out in #5468 that the `lang` attribute, when inherited
from a parent element, was above the option set in the global default
within the inheritance chain. While this makes sense because of how
we inherit other properties, it does not make sense for the `lang`
attribute.

The inheritance chain for the `language` option has been adjusted
to be the following:

1. The `lang` attribute on the original `<select>` element
2. The `data-language` attribute on the original `<select>` element
   (because of how `data-*` attribute resolution affects options)
3. The `language` option specified when initiailizing Select2
4. The `language` Select2 default
5. The `lang` attribute on a parent of the `<select>` element

While this is a breaking change, we believe that this change will
have minimal to no impact on real-world usage of Select2, because
of how the `lang` attribute is generally used within documents.
We believe this will now make setting the default language through
JavaScript easier and more reliable, bringing it in line with how
we recommend it is done within the documentation.

This was implemented through a new method `Defaults.applyFromElement`
instead of within the old `Options.fromElement` method because it
relies on the global defaults object. While we could have reached
in to the internals in order to apply it appropriately, it made
more sense to handle the proper resolution through a single
consistent place.

This was not implemented in the `Defaults.apply` method because that
method is not typically passed in a reference to the original
`<select>` element that it is applying the options for.

Closes #5468

* Properly resolve language chains with dictionaries

It is possible for a language chain to be specified that includes
both a dictionary and the string translation as a part of the same
chain, but we would previously throw an error because we assumed
that the list could only contain strings and that dictionaries
would never be included in lists.

This fixes the issue so language region normalization only occurs
when a string is specified in the language chain, which is what we
were previously assuming was the case but was not actually.

This also now resolves the entire language option during the
`Defaults.apply` method. This should be a no-op except for internal
tests, because the `Defaults.applyFromElement` method should almost
always be called in real-world scenarios.
2019-08-13 20:07:35 -04:00
Kevin Brown
4db849cd99 Update changelog for 4.0.9 2019-08-07 21:40:36 -04:00
Kevin Brown
dc4e83379c Recompiled dist for 4.0.9 2019-08-07 21:30:49 -04:00
Kevin Brown
7fab80268f Bump versions for 4.0.9 release 2019-08-07 21:26:10 -04:00
Kevin Brown
9ad1b9107b Converting tests to unix newlines 2019-08-07 21:25:01 -04:00
Luiz Américo
7b9cfcaaa0 Remove unused variables (#5554) 2019-08-07 07:24:17 -04:00
Kevin Brown
f13ba12bea
allowClear no longer shifts selections to a new line (#5603)
* allowClear no longer shifts selections to a new line

This fixes an issue that we have had with the "x" icon used by the
`allowClear` option where selections that just barely interacted
with the position of the "x" icon would be pushed to a new line
that was separate from the normal second line of selections. This
case was pretty rare, because you only had a ~9px area where the
interaction could occur.

The issue was cuased by the "x" icon being sized for the height of
the text in the selection choices, which should be the same as how
the selection choices themselves are sized. Unfortunately this did
not take into account the fact that the selection choices are given
a 1px border which increases their size by 2px, which is what lead
to the odd behaviour. This behaviour could not be replicated without
the 1px border because the height would then line up correctly.

The issue can be fixed by adding a 2px margin to the bottom of the
"x" icon, which would force overlapping selections on to the correct
second line of selections. This was the method that many users have
been using to correct this issue, but was not the method we chose to
use. A 1px padding has been added to the "x" icon instead, which
should expand the touch area of the "x" by a little while also
increasing the height of the "x" by enough to prevent the overlapping.

Fixes #4470

* Remove hard-coded height in tests

Because tests are executed on different browsers, and because each
browser sets their own line height, we cannot depend on the height
of the default Select2 being consistent across browsers. As a result,
we must write our tests to calcualte the expected height based on
known data. In the case of this test, we can calculate ahead of time
what two rows of selections is supposed to look like, instead of the
edge case that we can otherwise encounter.
2019-08-04 22:03:52 -04:00
Nagaraj Tantri
2ccdcb57c6 Updated grunt version so it no longer shows as vulnerable (#5597) 2019-08-04 01:58:52 -04:00
Kevin Brown
e5131d0cc8
Set the main ARIA 1.1 roles and properties for comboboxes (#5582)
* Move search accessibility tests under selection tests

* Set aria-activedescendent and aria-owns on selection search

This is a reduced version of a5ab08b49cb which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the selection container. This is the search
box used within a multiple select, and previously it did not always
set these two attributes correctly.

One major change here is that we clear the `aria-activedescendent`
attribute if the result that is selected does not have an ID. This
was not being done previously, instead the attribute was still
containing the old value, and it meant that sometimes the wrong
result was being pointed to.

The test coverage for this was also expanded to ensure that these
attributes are properly being set.

* Set aria-activedescendent and aria-owns on dropdown search

This is a reduced version of a5ab08b49cb which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the dropdown. This is the search box used
within a single select, and previously it did not set these two
attributes at all. Additionally, it did not set the `aria-autocomplete`
attribute, which is also needed for screen readers to properly read
through the list of results.

There was previously no test coverage for this, so the tests were
largely copied from the tests for selection search.

* Set proper ARIA roles on result elements

When Select2 4.0.0 was originally written, accessibility was tested
using the Orca screen reader and Mozilla Firefox as the browser.
Because a `<select>` box could contain `<optgroup>` elements, which
can further contain additional `<option>` elements, Orca would read
out a `<select>` box as a tree view. Apparently Orca was the only
screen reader to do this, but Select2 maintained this behaviour
because the ARIA spec did not allow grouping elements for the right
roles.

In the ARIA 1.2 spec, an element with the role of `listbox` (which
is the proper one for representing a `<select>` element) can now
contain elements with the role of `group` that can be used for
grouping. This means that now Select2 can switch to use the proper
ARIA roles to better match how most browsers represent the `<select>`
element out of the box.

As a result, instead of the Select2 results list being represented
as a tree containing tree items, it is now represented as a listbox
containing options and groups. Notices will be represented as an
alert, which more closely represents what they were being used for.

This is a reduced version of a5ab08b49cb which is split out to only
fix the `role` attributes on elements within the results list.

* Switch search boxes to have a role of searchbox

I'm pretty sure this is implicit now, but since we used to specify
that the search box had a role of `textbox`, we may as well migrate
that over to specify the role of `searchbox`. This is different
from the original pull request where this role was changes to
`combobox`, but that is because we are working against the ARIA 1.2
spec and the original pull request was working agianst the ARIA 1.0
spec, which required the search box to have that role.

* Set aria-controls instead of aria-owns on search boxes

In ARIA 1.1, there was a switch to use `aria-controls` on the search
box to point to the results list instead of using `aria-owns`. This
is required because the `combobox`, in our case the selection
container, should have the `aria-owns` attribute pointing to the
results list. And because only one elment can own another element,
we must fall back to `aria-controls` to represent that relationship.

The tests have also been adjusted to reflect this new discovery.
2019-07-29 22:34:24 -04:00
Kevin Brown
f14bdf6b7b
Fix search box expanding width of container (#5595)
This fixes a bug with the search box where, when it had a placeholder,
it would expand the width of the selection container because it was
too large. This bug was specifically caused by the search box not
factoring in the padding surrounding it when caclualting the width
it needed to be, which resulted in the search box extending
outside of the selection container. This bug was easy to notice if
your Select2 was set to have 100% width and if the container it was
held within was not a block element.

This fixes the bug by switching to using `width()` for calculating
the search width instead of using `innerWidth()`, which ignored the
surrounding padding.

Fixes #5517
Closes #5518
2019-07-29 22:25:19 -04:00
Kevin Brown
472e5ad50f
Fix dropdown positioning when displayed above with messages (#5592)
This fixes an issue which was usually observed when working with
AJAX results sets and having a message being displayed, usually the
minimum characters message or an error. The dropdown would display
up, like it was supposed to, but the message would appear to be
floating above the container and detached.

This was occuring because the dropdown position was not being
calculated whenever a message was displayed in the results, only
when the results were loaded or new results were appended to an existing
results set. There are plenty of situations where this could have
caused issues, but somehow most of the reports were around a very
specific situation with AJAX which could be reproduced on the
examples site.

Fixes #4614
Fixes #4616
Fixes #5253
Closes #5196
2019-07-28 15:16:30 -04:00
Kevin Brown
525f661915
Reposition dropdown whenever items are selected (#5590)
* Reposition dropdown whenever items are selected

This fixes an old bug where if you had a multiple select with the
`closeOnSelect` option set to `false` and many options being
selected, the dropdown would not reposition itself if the selected
options expanded the container down another line. This was because
the dropdown was only being repositioned when it was opened, closed,
or if something around it was scrolled or resized. Unfortunately,
in most cases none of these happened and the dropdown would start
covering the selections.

This was fixed by telling Select2 to resize the dropdown when new
options are selected or existing options are unselected.

Fixes #4377

* Attach positioning handlers at bind time

The positioning handlers have been attached at the time that the
dropdown is opened since when they were first committed many years
ago. It's not actually clear why this was being done, since they
don't rely on anything involving the dropdown being open. This
removes the flag and process for setting these handlers only after
the dropdown was opened for the first time, and moves these handlers
to always be set at bind time.
2019-07-28 14:49:25 -04:00
Kevin Brown
efbfd14414
Remove selection title attribute if text is empty (#5589)
This fixes a bug that was introduced in Select2 4.0.0 and only
partially fixed in Select2 4.0.6-rc.0 where the `title` attribute
that is set on the selection container (or individual selections,
for a multiple select) is not cleared when the text/title of the
option is not set. In most cases, users no longer see this issue
because the `text` property of most data objects is set, so the
`title` attribute will always be cleared correctly. There was a bug
for cases where the `text` property was not set, or where the `text`
property was set to an empty string, that resulted in the `title`
attribute persisting with the incorrect value.

We have fixed this issue by always removing the `title` attribute
from the selection (or not adding it in the first place, for a
multiple select) when the `text` and `title` properties of the data
object are empty or not present.

This also adds in a series of tests to ensure the `title` attribute
is set properly in a variety of cases, building upon the ones that
already existed.

Fixes #3895
2019-07-28 00:36:51 -04:00
Kevin Brown
6645ffd4bd
Select2 now clears the internal ID when it is destroyed (#5587)
This fixes a bug where if you cloned a Select2, the internal ID used
for mapping elements (specifically the `<select>`) to the in-memory
data store would be cloned as well, causing issues when you tried to
initialize Select2 on the cloned element. This was because we did not
properly clear all of the internal data and all of the internal
attributes that Select2 uses when we destroyed it. The internal
`data-select2-id` attribute was not being cleared, and this was the
attribute being used for the internal mapping.

Now we properly clear the `data-select2-id` attribute from the element
when we call `RemoveData` on the element. This aligns with what we
were trying to do, since we previously cleared out the internal store
for that ID, and fixes the issue we were seeing when cloning.

Fixes #5247
2019-07-27 21:37:43 -04:00
Kevin Brown
1f3eceba5a
Fix generated options not receiving result IDs (#5586)
In order to enable the ability to uniquely identify a result by an ID
in the DOM, we generate a new ID for the result based on a combination
of things, including the container ID prefix that is generated and
used elsewhere in Select2. This has worked fairly well for use cases
including attaching Select2 to an existing `<select>` and loading in
options from a remote data set.

Unfortunately, because this process relied on the container ID being
used as a prefix, this failed for options which were automatically
generated on initialization using the `data:` option to Select2.
These were not being generated with an ID because at the time that
they were being generated, the data adapter was not aware of the
container it was being used in. This broke some accessibility features
because we had a mix of options in the results list with IDs, and
some without, so we fixed the ordering to make this work.

Option generation no longer happens when the data adapter is first
initialized, which is where it was previously happening, and instead
it now occurs when the data adapter is bound to the container. This
allows us to ensure that the data adapter is always aware of the
container it is being associated with, so now it will be able to
generate the result IDs.

This also fixes the tests for the array adapter as well as the
legacy `<input />` adapter so they properly bind to a container
during the test. This was causing test failures becuase the options
which would previously be generated during initialization were no
longer appearing.

Fixes #4350
2019-07-27 16:37:57 -04:00
Kevin Brown
2fce8ae6c4
Fix maximumSelectionLength being ignored by closeOnSelect (#5581)
* Rewrote maximumSelectionLength tests to use container

These brings the tests in line with other tests which we have, and
makes it easier to understand what is actually going on in the tests.

This also removes a redundant set of tests where we were testing with
=> 2 options being allowed. There are no current edge cases that would
have required this.

* Fix maximumSelectionLength being ignored by closeOnSelect

There was a bug where the `maximumSelectionLength` option would not
kick in if the `closeOnSelect` option was enabled. Normally, this
was enabled by someone in their global configuration, but it could
also be seen when somoene selected an option while holding the
meta/ctrl/alt keys. This would implicitly enable the `closeOnSelect`
behaviour, even when it was not globally enabled, and cause the bug.

This fixes that issue by listening to the `select` event which is
triggered whenever an option is selected, and triggers the "maximum
selected" message based on that event. This should now force the
message to be displayed, even when the results did not have to be
queried another time.

Fixes #3514
Fixes #3860
Closes #5333
2019-07-21 15:44:37 -04:00
Kevin Brown
f2d527ea97
Do not propagate click when search box is not empty (#5580)
This fixes a long-standing bug where if you tried to click in the
search box for a multiple select while there was text in it, the
dropdown would close and the text would be cleared. This caused
many unexpected issues, because it meant that you could only use
your keyboard to edit text within the search box.

This will still clear out the search field if you click within the
area of the selection which is not the search field. I'm not sure
if that is also unexpected behaviour, so for now I am going to
maintain it.

Fixes #3517
Fixes #3808
Fixes #5491
Closes #5551
2019-07-21 13:04:51 -04:00
Kevin Brown
89576153a0
Mirror disabled state through aria-disabled on selection (#5579)
This is needed to screen readers know that the Select2 is disabled
when focus is put on the selection container. Because we were
mirroring the disabled state to the search input on a multiple
select in the past, this is really only needed for single select
elements which would not otherwise has the disabled property.

This was identified in a previous accessibility audit as being
something which Select2 did not properly report because we were
not setting the attributes properly.

Fixes #4575
2019-07-21 11:44:09 -04:00
Kevin Brown
eeefa1e449
Merge pull request #5577 from select2/release/4.0.8
[Release] 4.0.8
2019-07-20 23:12:39 -04:00
Kevin Brown
5005c564c2 Update changelog for 4.0.8 2019-07-20 23:09:14 -04:00
Kevin Brown
8b55e47604 Recompile dist for 4.0.8 2019-07-20 23:05:45 -04:00
Kevin Brown
6fbe132e50 Bump versions for 4.0.8 release 2019-07-20 23:02:46 -04:00
Kevin Brown
bbd320d75e Convert source and tests to unix newlines 2019-07-20 23:01:38 -04:00
Kevin Brown
1b5a962819
Revert change to focusing behaviour in 4.0.6 (#5576)
This behaviour, where the focus was happening on a small asynchronous
delay, was added in commit 933189b92 late last year in a commit with
no supporting tickets or commit message explaining what the change
was trying to accomplish. This commit has effectly been reverted within
this commit, since it caused a regression in how focus was being
assigned that made it inconsistent with a standard `<select>`.

A test was added for this which ensures that we won't see that
regression again.

Fixes #5532
Fixes #5185
Closes #5552
2019-07-20 22:44:28 -04:00
Kevin Brown
d9260254c1
Fix infinite scroll when the scrollbar is not visible (#5575)
Ever since the 4.0.0 release of Select2, there has been a bug where
if you enabled infinite scrolling but did not return enough results
on the first load of AJAX to show a scrollbar, then infinite
scrolling would not be enabled and you could not view anything other
than the first page of results. The solution for this was first
proposed in #3888 but it was closed off because of inactivity and
missing tests.

This fixes the issue by performing the check to see if more results
should be loaded both on scroll and also when the results are first
loaded. This solves the issue that we were seeing before, because
the plugin knows it needs to load in more results, just it did not
receive the scroll event before and thus was not able to actually
load in the new results.

This has the potential to trigger multiple AJAX requests to load in
multiple pages of results if the user has the ability to see many
options, but only a few are being loaded at a time.

This also adds tests for infinite scrolling, both to ensure that
it will attempt to load additional pages, even without the scrollbar,
and to ensure that the regular behaviour of not loading additional
pages when the scrollbar is visible is preserved.

Fixes #3088
2019-07-20 18:09:17 -04:00
kevin-j-morse
8a5aeabcce Remove deprecated jQuery shorthand (#5564) 2019-07-20 16:05:48 -04:00
Min ho Kim
9c4f0c86a1 Fix typos (#5574) 2019-07-20 12:42:18 -04:00
Kevin Brown
bd7ac9df03
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-09 20:58:13 -04:00
Kevin Brown
b5f136ff72
Add computedstyle option for calculating the width (#5559)
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 #3278
Fixes #5502
Closes #5259
2019-07-09 19:44:33 -04:00
Kevin Brown
f9decd6094
Fix tag creation being broken in 4.0.7 (#5558)
* 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 #5485
Fixes #5516
Closes #5550
2019-07-09 19:13:03 -04:00
Kevin Brown
9491e1aae2
Test against jQuery 3.4.1 (#5531)
* Update tests to be compatible with jQuery 3.0.0

There was a change in jQuery 3 that ensures that the return value of `.val()` on a multiple select is always an array. This is a breaking change from previous versions, where `null` or `undefined` were returned in these scenarios. Because we cannot `assert.equal` on a list of possible values, these assertions were switched to `assert.ok` which should be good enough.

* Properly strip out units in positioning tests

Before we were assuming that there were no units, and only were we stripping them out if we were expecting 3 digits. Now we just strip out all non-digit characters, so that should do the job and get us what we want.

There was a change in jQuery 3.2.0 that caused the units to be returned in these specific calls. They were not previously being returned, so this was not actually an issue.

* Add automated testing against jQuery 3.4.1

No tests appear to be currently failing.
2019-06-25 22:05:15 -04:00
Waseem Ahmad
d66e55dd9e removed select2-selection__placeholder from _multiple.scss (#5508) 2019-06-25 21:59:56 -04:00
Kevin Brown
5d2fdd75b5
Update grunt-contrib-qunit to latest version (#5530)
We needed to define the `qunit` module in the unit tests because there was a change in grunt-contrib-qunit 0.6.0 that breaks when you define an AMD loader. It expects that the AMD loader is also used to load QUnit, instead of just being used to support the tests, so if you don't define the qunit module it will just hang and do nothing. Luckily we have the helpers file to help us out here, since it allows us to globally define this module.
2019-06-04 22:43:52 -04:00
Kevin Brown
70ca392a43
Update dev dependencies (#5529)
* Update dev dependencies

* Adjust dependencies versions to avoid unmet peer dependency error

* Update Travis CI node version to 8

* Recompile dist

This updates all of the minified files to use the latest uglifyjs version, which results in better compression (by a small margin).
2019-06-04 21:18:37 -04:00
bufferUnderrun
36b226d509 Improve French Translation (#5521)
better translation of the english word "items" to "éléments"
2019-06-04 20:47:35 -04:00
Kevin Brown
d53958ad2b
Clean up docs (#5528)
* Remove SauceLabs credentials

SauceLabs is no longer used during builds, so we no longer need to include these encrypted credentials.

* Clean up badges

* Remove SauceLabs from the README

* Misc README fixes

* Disable Travis email notifications

Looks like we accidentally re-enabled these when removing IRC.
2019-06-04 20:46:45 -04:00
Kevin Brown
0a612f92e1
Automatically deploy to NPM (#5527)
* Added deployments to NPM on tagged releases

Previously this was being done manually after each release, which resulted in a few releases not showing up on NPM for  a significant amount of time. Now the builds should be automatically pushed, which should hopefully improve a lot of the issues we were seeing.

* Drop IRC notifications

We no longer use this IRC channel.

* Clean up .travis.yml

* Remove grunt ci

This is no longer needed now that we don't do anything special for CI builds. This also allows us to minify during CI builds, which will be useful for the tagged builds which depend on these minified files being up to date (so they can get released as well).
2019-06-04 20:26:11 -04:00
Kevin Brown
04fce55967
Merge pull request #5507 from select2/develop
Release Select2 4.0.7
2019-05-07 16:14:21 -04:00
Kevin Brown
f8193c6c82
Merge pull request #5506 from select2/release/4.0.7
[Release] 4.0.7
2019-05-07 16:08:47 -04:00
Kevin Brown
5285eef7b5 Recompile dist for 4.0.7 2019-05-07 16:05:00 -04:00
Kevin Brown
20ffd1296a Bump versions for 4.0.7 release 2019-05-07 16:02:59 -04:00
Kevin Brown
d0ddab6ceb
Merge pull request #5494 from select2/develop
Release Select2 4.0.7-rc.0
2019-04-30 23:44:31 -04:00
Kevin Brown
df3c343490
Merge pull request #5493 from select2/release/4.0.7-rc.0
[Release] 4.0.7-rc.0
2019-04-30 23:41:42 -04:00
Kevin Brown
2596f2ab9c Update changelog for 4.0.7-rc.0 release 2019-04-30 23:37:24 -04:00
Kevin Brown
647533e981 Recompile dist for 4.0.7-rc.0 release 2019-04-30 23:37:08 -04:00
Kevin Brown
48e2f56fea Bump versions for 4.0.7-rc.0 release 2019-04-30 23:33:21 -04:00
Carlos Abalde
f6c455cea9 Do not close on select if Ctrl or Meta (Cmd) keys are being held as described in #3400 (#5222)
Fixes #3400
2019-04-30 23:29:11 -04:00
Kevin Brown
2a5f46bcc4
Move almost and jquery-mousewheel to devDependencies (#5489)
These two are required at build time to generate the full builds
of Select2 (for jQuery Mousewheel) and to inject the AMD loader
(for Almond.js). They are not required for anyone who depends on
Select2, since jQuery Mousewheel is an optional dependency.

This may result in some people needing to add jQuery Mousewheel to
their projects as a required dependency, if they were expecting
it to be added by Select2 before.
2019-04-30 23:15:22 -04:00