Due to the fact the widget factory code is now in strict mode, the check for
being called without using the `new` keyword started breaking if you save the
widget constructor to a variable before calling it:
```js
var customWidget = $.custom.customWidget;
customWidget( {}, elem );
```
as then `this` is undefined and checking for `this._createWidget` crashes.
Account for that with an additional check.
Fixes gh-2015
Closes gh-2019
PR gh-1793 removed setting `this.offset.parent` in the Draggable
`refreshPositions` method which broke position calculations when moving
a Draggable item into a connected Sortable. restore that assignment.
Ref gh-1793
Fixes gh-2001
Closes gh-2009
Note that container specific events will not fire when the dragged element
is interacting with zero height containers.
Fixes gh-1998
Closes gh-2008
Co-authored-by: A. Wells <borgboyone@users.noreply.github.com>
Commit 1f2011ece removed a `try-catch` around triggering the `remove` handlers
in the `jQuery.cleanData` override. The `try-catch` was meant for old IE but it was
also catching an error coming from the tooltip `remove` handler depending on
being able to find a relevant tooltip. The `_find` method returns `null`, though,
when the tooltip cotent is empty.
Instead of restoring the `try-catch`, handle the `null` case in the `remove` handler.
Fixes gh-1990
Closes gh-1994
Co-authored-by: Claas Augner <github@caugner.de>
Co-authored-by: Michał Gołębiowski-Owczarek <m.goleb@gmail.com>
Add a new option named onUpdateDatepicker that allows a custom callback
to be provided. If provided, the callback is called at the end of
$.datepicker._updateDatepicker.
Instead of using enormous HTML strings, various elements are now constructed
using jQuery APIs. This makes it more obvious user-provided data is used
correctly.
Fixes#15284
Closes gh-1953
In IE in jQuery 3.4+ a sequence:
```js
$( inputNode ).trigger( "focus" ).trigger( "blur" ).trigger( "focus" );
```
doesn't end up with a focused input. However, in this test we only want to check
that the last focused input receives the focus back when `_focusTabbable()` is
called which in reality doesn't happen so quickly so let's avoid the issue by
waiting a bit.
Ref jquery/jquery#4856
Closes gh-1951
Some of the APIs return fractional values in newer jQueries, making comparisons
sometimes not being 100% accurate. Allow some delta.
This is similar to what was already done in
98b539171b but a few cases affecting IE and/or
Edge Legacy were missed.
Closes gh-1947
jQuery 3.2 & newer have a different animation logic and the animated elements
width/height differ from the starting ones even at the beginning of the
animation. The point of the assertions checking that they're identical was
to ensure bug #5245 is fixed; that issue manifested by a big jump to half the
element size. To test for that, it's enough to check that the first obtained
values are close to the original ones.
This makes effects tests pass in all supported jQuery versions.
Closes gh-1928
Ref #5245
This helps fix issues that make tooltip tests sometimes fail when run against
jQuery 3.2 or newer due to timing differences.
Details:
* Add the `moduleAfterEach` function ensuring no timers are running.
* Attach this function via `common.testWidget`.
* Attach this function to most test suites.
* Add a tooltip test helper cleaning up leftover timers.
* Rename legacy `setup`/`teardown` hooks to `beforeEach`/`afterEach`.
Closes gh-1920
jQuery positional selectors () have been deprecated in
[jQuery 3.4.0](https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/)
and they'll be removed in jQuery 4.0.0. This PR removes their usage.
Most of the changes were possible without changing public API. However,
dropping `:even` usage required a change to the
[`header` option](https://api.jqueryui.com/accordion/#option-header)
of the accordion widget. I made it an optional function; this will need
to be documented.
The polyfill for `.even()` & `.odd()` is added for jQuery <3.5.0. There was
no usage of the :odd selector in the code but the `.odd()` method is also
polyfilled for completeness.
Closes gh-1904
Summary of the changes:
* Build: Add jQuery 3.2.0-3.4.1 to versions UI can be tested against
* Build: Load jQuery & Migrate via HTTPS
* Build: Add package-lock.json to .gitignore
* Build: Update jQuery Migrate from 3.0.0 to 3.1.0
* Build: Allow to run tests against jQuery 3.x-git
* Build: Fix formatting according to JSCS rules
* Build: Disable JSCS for the inlined jQuery Color
* All: Switch from $.isArray to Array.isArray (jQuery.isArray will be
removed in jQuery 4.0)
* All: Switch from `$.isFunction( x )` to `typeof x === "function"`
(jQuery.isFunction will be removed in jQuery 4.0)
* All: Inline jQuery.isWindow as it'll be removed in jQuery 4.0
* Effects: Fix a timing issue in a variable declaration. Previously,
a jQuery object was created, chained & assigned to a variable that
was then accessed in a callback used inside of this chained
definition. Due to a timing difference in when the callback fired for
the first time in latest jQuery master, it was being called before
the variable was defined.
* Tests: Make dialog & draggable unit tests less strict (newest jQuery
returns fractional results in some cases, making comparisons fail when
there's a tiny difference)
* All: Migrate from $.trim to bare String.prototype.trim (jQuery.trim
will be deprecated in jQuery 3.5)
Closes gh-1901
I was running into a problem with a popup menu control in a dialog; clicks
weren't working (but keyboard was working fine). It turned out that the menu
was getting destroyed before the click event could fire.
Tracked down the issue to the way draggable blurs focused controls; it was
doing the blur before it ran through the logic to figure out if the drag was
actually on the handle. I've moved the blur below these checks, so it'll only
blur things if it actually needs to handle the drag. Otherwise, it asserts no
opinion on what should and shouldn't be focused, which seems like the way
things ought to be.
Also, added a unit test to check for the expected behavior.
Fixes#15046
Closes gh-1730
With jQuery 3 using `requestAnimationFrame()`, the `setTimeout()` timing
for short animations wasn't working consistently. This resulted in infrequent
failures everywhere (but infrequent enough that it's hard to even notice), but
consistent failures in IE and Edge. Bumping up the duration and running the
assertions in the middle seems to give consistent results.
Eventually, we should refactor this to use `requestAnimationFrame()` in the
tests themselves to avoid problems like this.
Closes gh-1738
