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
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
These failed when running through tests/unit/all.html, due to the smaller
iframe. Reducing a browser window enough triggered the same issue. Making
the top offset much smaller fixes that.
The rest is fixing bad indent and adds a missing module call.
Draggables now forcefully recalculate their position when dragged out
of a sortable. Sortables now override draggable position when a
draggable is dragged into it. Lastly, no longer remove sortable helper
when dragging a draggable out, which allows us to not use a clone.
Fixes#7734Fixes#8809
Closes gh-1322
This prevents the firing of mouseup in the case of IE<9, which will
fire a mousemove event if content is placed under the cursor on
mousedown.
Fixes#7778
While it is true that overflow:hidden elements can be scrolled
programatically, this breaks user expectation. Therefore, do not
scroll inside an overflow:hidden container.
Developers can programmatically set scrollTop/Left on
draggable containers that are overflow:hidden. They must
be considered for positioning.
Fixes#10147
