search

unoplatform / uno

Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
https://platform.uno
Apache License 2.0
8.42k stars 685 forks source link

Skia touch doesn't work well for scrolling #16372

Closed Youssef1313 closed 1 week ago

Youssef1313 commented 1 week ago

Current behavior

When having a ScrollViewer on Skia on a touch device, if you press with finger, move the finger, and release it (i.e, scroll with the finger), the event sequence will be pointer pressed, few pointer moved, then pointer released.

This behavior is not correct and doesn't match WinUI.

Expected behavior

On WinUI, once you start moving (regardless of whether that move causes a scroll or not), you get a PointerCaptureLost, and then you don't get any more events.

How to reproduce it (as minimally and precisely as possible)

  1. Open WPF SamplesApp on a touch device
  2. Press with finger somewhere on the samples list
  3. Start moving the finger slowly (the bug may not repro with fast scrolling)
  4. Release finger
  5. The pressed sample/category will be opened.

Workaround

No response

Works on UWP/WinUI

Yes

Environment

No response

NuGet package version(s)

No response

Affected platforms

No response

IDE

No response

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

NOTES:

  1. The current behavior can cause scrolling to click on an element when it shouldn't.

  2. The way this works in WinUI is that ScrollViewer uses Direct Manipulation (see https://learn.microsoft.com/windows/win32/directmanipulation/direct-manipulation-portal):

    When the user performs a pan, a WM/_POINTERCAPTURECHANGED message is sent to the application to notify that the contact has been consumed by Direct Manipulation.

  3. Then, WinUI's PointerInputProcessor will receive the POINTERCAPTURECHANGED window message, and will raise PointerCaptureLost event.

  4. No more events are received. So we don't receive a PointerReleased (which is a source of evil in this case)

dr1rrb commented 1 week ago

This depends of the ManipulationMode used in your visual tree. The behavior you described is when you let the default System mode (which allows direct manipualtions ). Basically it's a hack to inform the application that, for performance consideration, it won't get the pointer events anymore. If plan didn't changed, this mode is to be deprecated by the new ScrollView.

As we don't have such "direct manipulation" in uno, it's doesn't really make sens to implement it this way as anyway it's only confusing for user.

dr1rrb commented 1 week ago

Let me clarify : yes we need to fix the fact the sub elements should not get the events. (Explicit capture the pointer on the ScrollContentPresenter is probably enough, and it has to get priority over any existing capture - like a Button.Click).

But I don't think that we should have a dedicated dispatch path of pointer events like they have on windows.

Basically it means that parent element will still be able to see pointer events, while on windows they are not able to.