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.
