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
Remove an incorrect fix introduced in 47cd5b6f that causes
width calculations to be incorrect once the correct fix
was introduced in c03cb807Fixes#10140
Selectmenu's test suite broke with b0e8380, which changed the padding
used by the menu widget. Selectmenu conditionally adds pixels to the
menu's width, and using closeEnough() accounts for that and the
rounding differences across browsers.
Closes gh-1275
If event.isDefaultPrevented() is true, the focus management is
completely skipped, assuming the user manages focus manually.
Fixes#10103
Closes gh-1265
Copy-paste error introduced in df6110c0d4
Updates the tabbing test to be more specific about which element should
have focus, instead of only checking if focus is within the dialog.
Ref #9646
Ref #10103
Closes gh-1264
The plugin isn't needed nor used in the unit tests, which just trigger the
appropriate events. This works around the failure in Firefox 27/28 that we'll
try to track down separately.
Ref #9988
This adds a compound test page for draggable+resizable, which had no coverage
before. Using that page shows that there is no way to reproduce the behaviour
described in the original ticket that caused this workaround, since its not
possible to resize an element beyond the window boundaries. Therefore removing
the workaround, which is 6+ years old and has no test coverage, seems like the
sanest approach.
Fixes#6939
Closes gh-1210
Switching to checking the size of the content element. We should be
checking the dimensions of the .ui-dialog element, but that currently
fails in Chromium-based browsers. Once we start using box-sizing:
border-box, we should try to revert this change.
Ref #9845
Calling element.focus() causes scroll in IE. In order to correctly test scroll behavior,
we must calculate scrollTop on the drag event, before .focus is called.
Calling element.focus() causes scroll in IE. In order to correctly test scroll behavior,
we must rely on the actual calculated offset instead of the helper offset to ensure
cross browser test consistency.
Some unit tests were disabled in phantomjs. Dialog and draggable
depended on a larger viewPort. Tooltip just worked, that was reenabled
as well.
Closes gh-1173
This fixes an issue where contenteditable text was getting overwritten when
wrapping past the bottom or top of the autocomplete menu.
Fixes#9771
Closes gh-1184
If containment was set such that relative_container is set by
_setContainment, and then containment changes to e.g. "document",
"window", or an array, relative_container would not be unset, causing
incorrect containment of the draggable.
Add a unittest to check that containment with an array works after
previously being set to "parent".
Fixes#9733
Closes gh-1176
The test count was previously incremented to 8 when normally 6 tests
are run. After figuring out the dynamic test code, I just made the
expect depend on the same array length
Also re-enabled the test in the Gruntfile since it now passes.
Ticket #8925 states that changes to the title attribute while the
tooltip is open are lost on tooltip close.
In the close and destroy functions, the title attribute is always
written if a value was stored in the element on open. It is possible
the attribute has changed and restoring the initial value may overwrite
the current value.
If the value is empty or undefined as set in open, do not set the title
attribute.
This fix has the limitation that if the user removed the title
attribute or set the value to an empty string the original title value
would be restored on close and destroy.
Fixes#8925