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
