Don't send synthetic Move events before Press/Release for touch #870
Conversation
These kind of synthetics were added to fix missed Enter/Exit events: Box1 | Box2 If we have this chain of native events: ``` Move on Box1 Press on Box1 Release on Box2 Move on Box2 ``` Without synthetic events, Compose receives: ``` Enter on Box1 Press on Box1 Release on Box1 (because Box1 takes ownership of the all events) Enter on Box2 ``` With synthetic events: ``` Enter on Box1 Press on Box1 Exit on Box1 Release on Box1 Enter on Box2 ``` Touch doesn't have Enter/Exit, so we don't have to send them. Furthermore, such kind of synthetics can bring issues when calculating the end fling velocity (the end position should be excluded from the velocity calculation on iOS). This isn't an issue for mouse. ## Testing - run existing tests - run iOS demo and try usual cases ## Issues Fixed https://youtrack.jetbrains.com/issue/COMPOSE-474/Fix-synthetic-events-before-end-event-with-different-position
| @@ -972,6 +972,7 @@ private fun pointerInputEvent( | |||
| it.pressed, | |||
| it.pressure, | |||
| it.type, | |||
| issuesEnterExit = it.type == PointerType.Mouse, | |||
There was a problem hiding this comment.
Why do we need issuesEnterExit field at all? It seems that type == Mouse should be enough.
If we really need it, I suggest adding a doc comment with the reason why it's needed and probably rename to something like issuesHover
There was a problem hiding this comment.
It isn't a new field, it was added by Google in commonMain and it means that the pointer can move between nodes and generate Enter/Exit. It exists and used by the internal common code, so we have to set it anyway.
As for checking type == Mouse instead, it is always better to check a characteristic of the pointer, not a specific type of it. Imagine, we add a new pointer VR Controller, we have to add it everywhere where we added Mouse. Stylus also can support hover without pressing the screen.
I don't like issuesEnterExit, issuesHover sounds better, but we already have it, so we can't change it easely. Added a comment in SyntheticEventSender.
The same is applicable for our other checks. For example, for primary press checks we should add something like isPrimaryButtonCausesDown (naming is hard).
| background.events.assertReceived( | ||
| PointerEventType.Release, | ||
| touch(1f, 1f, pressed = false, id = 1), | ||
| touch(1f, 2f, pressed = true, id = 2), | ||
| touch(10f, 55f, pressed = false, id = 1), |
There was a problem hiding this comment.
The position of synthetic Release equals the position of the last Move. Because we don't have a synthetic move before Release, we take the real's Move position, not synthetic one.
| @@ -313,6 +313,11 @@ class DragGestureTest { | |||
| assertFalse(dragCanceled) | |||
| assertFalse(dragEnded) | |||
|
|
|||
| scene.sendPointerEvent( | |||
There was a problem hiding this comment.
This is sent because we test a drag to Offset(5f + viewConfiguration.touchSlop, 15f), position. But because it is different from the previous Move position and we don't send a synthetic now, we send a real Move now
These kind of synthetics were added to fix missed Enter/Exit events: Box1 | Box2 If we have this chain of native events: ``` Move on Box1 Press on Box1 Release on Box2 Move on Box2 ``` Without synthetic events, Compose receives: ``` Enter on Box1 Press on Box1 Release on Box1 (because Box1 takes ownership of the all events) Enter on Box2 ``` With synthetic events: ``` Enter on Box1 Press on Box1 Exit on Box1 Release on Box1 Enter on Box2 ``` Touch doesn't have Enter/Exit, so we don't have to send them. Furthermore, such kind of synthetics can bring issues when calculating the end fling velocity (the end position should be excluded from the velocity calculation on iOS). This isn't an issue for mouse. ## Testing - run existing tests - run iOS demo and check that click, and scrolling works ## Issues Fixed https://youtrack.jetbrains.com/issue/COMPOSE-474/Fix-synthetic-events-before-end-event-with-different-position
These kind of synthetics were added to fix missed Enter/Exit events:
Box1 | Box2
If we have this chain of native events:
Without synthetic events, Compose receives:
With synthetic events:
Touch doesn't have Enter/Exit, so we don't have to send them. Furthermore, such kind of synthetics can bring issues when calculating the end fling velocity (the end position should be excluded from the velocity calculation on iOS). This isn't an issue for mouse.
Testing
Issues Fixed
https://youtrack.jetbrains.com/issue/COMPOSE-474/Fix-synthetic-events-before-end-event-with-different-position