Fix Table column header sorting on Chrome (#14796)
This fix is similar to the fix that has been made for other similar
cases (i.e. #13381).
Couldn't find a reliable way to reproduce the problem. Hopefully this
will fix the issue.
Was reproduced (before fix) on Google Chrome 40.0.2214.115 m on
TableSortingStopsWorkingOnChrome test one time (but then suddenly it
started to work again).
Was reproduced (before fix) on Project TableSorting once, as described
in the ticket. That project has been attached to the ticket.
Change-Id: Id901c9ce4a0a7c369572bf4374223851658aa703
Changed implementations and APIs to use the non-deprecated Element class
wherever possible without breaking backwards compatibility.
* Methods defined in interfaces have not been touched.
* Return types have only been changed methods that should have no
existing third party callers (i.e. private, internal or @since 7.2)
* For methods that third party code might have overridden, the method
has been deprecated in favor of a new method that just delegates to the
old method.
* For methods that can't reasonably be overridden by third party code
(i.e. private, final, static, internal or @since 7.2), the parameter
type has been changed without retaining the old method.
Change-Id: I7da943a77b8d0d0b9185d8c70f87d676a275d24b
Preventing premature start of drag due to Chrome move event #13381
The drag only actually starts when the mouse move or touch move event is
more than 3 pixel away.
The purpose is twofold:
a) it fixes the glitchy behaviour of Chrome which for some reason
sometimes fires a move directly after the mousedown, which starts a drag
immediately.
b) it helps people with shaky hands or imprecise hardware, why might not
want to drag but to select but slightly move the pointer. Some frameworks
opted to make the distance configurable.
Due to sub pixels (which might be the cause for a) in the first place),
a distance of 1 or 2 pixel is not enough. Experiments showed that unaware
users did not notice that 3 pixels movement are required for the drag to
actually start (the ghost has already a delay of 300ms)
Change-Id: I71b50b72486344a7dbe4ed927b34b1f8fab0db20
Fixed DragAndDropWrapper using wrong drop target in IE8 #12406
VDragAndDropManager was assuming that the target element will always be
inside the cloned "drag image" element while dragging. This assumption
is false since the "drag image" can be 0x0px or transparent effectivly
disabling dragging.
Since Testbench 2 is also very flaky in using the Vaadin locators with
the drag/drop commands I replaced the locators with shorter locators
using a debug id to make the test more readable and stable.
Change-Id: I2cc9683d11e982521e74418c74dd3e81ee617ac5
Artur Signell
Teemu Suo-Anttila
Denis Anisimov
Maciej Przepióra
Anna Miroshnik
Leif Åstrand
Henri Sara
Fabian Lange
Matti Tahvonen
John Ahlroos
Marc Englund
Anna Koskinen
Automerge
Artur Signell
Matti Tahvonen
John Alhroos