Skip to content

Conversation

kevin-brown
Copy link
Member

No description provided.

kevin-brown and others added 19 commits June 4, 2019 20:26
* 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).
* 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.
better translation of the english word "items" to "éléments"
* 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).
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.
* 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.
* 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
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
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
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
This behaviour, where the focus was happening on a small asynchronous
delay, was added in commit 933189b 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
@kevin-brown kevin-brown merged commit a389a6d into master Jul 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants