diff options
| author | Vladislav Kaznacheev <kaznacheev@google.com> | 2016-01-15 15:37:05 -0800 |
|---|---|---|
| committer | Vladislav Kaznacheev <kaznacheev@google.com> | 2016-01-15 15:37:05 -0800 |
| commit | d0ed8937ce07e7243d8349d6eb859e8bff24f50b (patch) | |
| tree | b78bf8b3ff94454d16af2dd4e211ccdff9017412 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | fadc86666f25e3d773be01c746bfae17a860cd6a (diff) | |
Send ACTION_DRAG_LOCATION right after ACTION_DRAG_STARTED
When an app is both drag and drop origin and recipient, it might not
get ACTION_DRAG_ENTERED in some cases. Specifically, when
mouse is long-pressed and released in place, the sequence
of drag events is: ACTION_DRAG_STARTED, ACTION_DROP,
ACTION_DRAG_ENDED. This is happening because
ACTION_DRAG_ENTERED is emitted from ACTION_DRAG_LOCATION
handler (which is never called since mouse has not moved).
This problem does not exist with touch because (at least according
to observable behavior on Nexus 9) when drag and drop is initiated
by touch, MotionEvent.ACTION_MOVE immediately follows
MotionEvent.ACTION_DOWN (which normally causes
View.startDragAndDrop).
This CL fixes this problem by sending a single ACTION_DRAG_LOCATION
right after ACTION_DRAG_STARTED.
Bug: 26566708
Change-Id: Ifc8dd1005c04a5c8f0dc3f14be9e4839204cf281
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions