`Button` events are improperly raised/not raised for the three `ClickMode` modes on various platforms

[mikebmcl]

Current behavior

Testing on WASM, Android, and Skia-Gtk revealed that button events don't match UWP's behavior and that on UWP the events that should be raised depend on which of the ClickMode values a button is set to have. For WASM I tested using MS Edge, Chrome, and Firefox and found that the behaviors vary on Edge/Chrome versus Firefox. I'll post my detailed test results as a comment to this report because it's rather long.

Expected behavior

Button events will be raised at the same times and under the same circumstances as they are on UWP.

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

Run the SamplesApp Buttons->Button_Events sample, changing between the three ClickMode values on the various platforms. The default ClickMode is ClickMode.Release so that's what the sample currently tests (there are differences from UWP even on that mode but most only show up for touch input and the ones that do show up for mouse are easy to miss).

To ease that testing I created three SamplesApp tests that use Button_Events as a starting point, adding one test for each of the three ClickMode values (Button_Events_Hover, Button_Events_Press, and Button_Events_Release) with a modified UI so that it could be tested on Android (and other small form-factor devices). I'm going to submit them as a test: PR in hopes that they will be useful.

Workaround

None.

Works on UWP/WinUI

No response

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia

NuGet package version(s)

The current main branch of the uno repo except for skia which I tested using the /dev/dr/runtimeUITests branch because it resolves some Skia issues that could've affected testing.

Affected platforms

Android, WebAssembly, Skia (GTK on Linux/macOS/Windows)

IDE

Visual Studio 2022

IDE version

17.0.5

Relevant plugins

No response

Anything else we need to know?

I'm unable to test this on iOS, macOS, Skia/Tizen, skipped testing on Skia/WPF, and only tested WASM on Edge, Chrome, and Firefox. It's likely that those other platforms and that other browsers with WASM will have their own event behavior differences. I skipped testing on Skia/WPF because the issues I found with Skia/Gtk revealed problems that made testing further on Skia revealed two bugs that made further testing unlikely to be of any value before they are fixed.

[mikebmcl]

Results from running the tests using the tests in #7892 on WASM (Edge/Chrome and Firefox), Android, and Skia/Gtk. (Note: I originally started testing this using the existing Button_Events SamplesApp test but realized that creating individual tests for each of the three ClickMode types with small form-factor friendly UI made testing much easier. The tests can be run using Button_Events on WASM, Skia, etc. and will produce the same behaviors except that it does not test the PointerCaptureLost event so you'd need to add a test for that to Button_Events to test that event.)

WASM (Windows 11 Pro Version 10.0.22000 Build 22000) (Edge 97.0.1072.62 (Official build) (64-bit)) (Firefox 96.0.2 (64-bit)) (Chrome 97.0.4692.99 (Official build) (64-bit))

Note: Unless otherwise noted, the problems below occur on all tested browsers.

Firefox: Touch: All buttons in all Events tests: Visual state when starting a touch inside a button and then moving outside does not change until the button is released. Firefox using a mouse, UWP, Chrome, and Edge all change visual state as soon as the pointer leaves the button.

Hover Mouse:

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press.
• Pointer Released is not raised when clicking mouse outside of the button then releasing within it.

Hover Touch:

• All Buttons: When a touch begins within a button and is moved around within the button, the visual state will switch to something between pressed and not pressed and then will switch to not pressed even though the touch is still being held down within the button.
• Tapped occurs no matter how long you hold the button rather than the ~1 second time limit of UWP
• Double Tapped is never raised
• Clicked occurs when the touch starts within the bounds of the button. It does not occur and the visual state fails to change when the touch starts outside the bounds of the button and is moved into its bounds.
• Pointer Released does not occur when the touch starts outside of the button and is released within it nor does the button's visual state change when the touch moves within the bounds on the button
• Pointer Entered is not raised when the touch starts outside of the button and is moved within its bounds nor does its visual state change.
• Edge and Chrome: Pointer Leaved is not raised when the touch moves outside the bounds of the button, both when the touch begins inside the button and when it begins outside, is moved in, and then is moved back out. Visual state fails to when starting outside the button.
• Firefox: Pointer Leaved is not raised when the touch starts outside the bounds of the button, is moved in, and then is moved back out. Visual state fails to change. (Unlike Edge, Firefox correctly handles starting the touch inside the button and moving it out.)
• Edge and Chrome: Pointer Capture Lost is raised when touching the button and moving the touch (it does not matter if the movement stays within the button or moves outside it).
• Firefox: Pointer Capture Lost behaves correctly.

Press Mouse:

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press.

Press Touch:

• Pointer Released is not raised.
• Pointer Entered is not raised when the touch starts outside of the button and is moved within its bounds nor does its visual state change. Pointer Entered is only raised the first time when the touch starts inside of the button and moves out then in then out, etc. On Edge and Chrome, visual state changes from pressed to not pressed on moving out of the button's bounds the first time but does not change after that (i.e. the button won't change to a highlighted or pressed state when the touch pointer moves back inside the bounds of the button); Firefox does correctly change visual state, but like Edge and Chrome does not actually raise the event again.
• Edge and Chrome: Pointer Leaved is not raised when the touch moves outside the bounds of the button, both when the touch begins inside the button and when it begins outside, is moved in, and then is moved back out. Visual state fails to change in both cases.
• Firefox: Pointer Leaved is not raised when the touch starts outside the bounds of the button, is moved in, and then is moved back out. Visual state fails to change. When the touch starts inside the button and moves out, Pointer Leaved is not raised until the touch is released, meaning that only one event is raised even though the pointer might enter and exit the button multiple times, though visual state does correctly change between pressed and not pressed when starting inside the button.
• Edge and Chrome: Pointer Capture Lost is raised twice when touching the button and moving the touch outside of the bounds of the button, immediately if you do not wait two seconds before moving the touch or if you do wait then once when the 2 second timer triggers capture lost and then again when moving the touch outside of the button's bounds. If you hold it for the two seconds and then release without moving, it will be raised correctly (i.e. only at the end of the two seconds).
• Firefox: Pointer Capture Lost behaves correctly.

Release Mouse:

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press.

Release Touch:

• Double Tapped is never raised.
• Edge and Chrome: Clicked is not raised when touch starts in the button, is moved outside the button's bounds, then is moved back in and released.
• Firefox: Click behaves correctly.
• Pointer Entered is not raised when the touch starts outside of the button and is moved within its bounds nor does its visual state change. Pointer Entered is only raised the first time when the touch starts inside of the button and moves out then in then out, etc. On Edge and Chrome, visual state changes from pressed to not pressed on moving out of the button's bounds the first time but does not change after that (i.e. the button won't change to a highlighted or pressed state when the touch pointer moves back inside the bounds of the button); Firefox does correctly change visual state, but like Edge and Chrome does not actually raise the event again.
• Edge and Chrome: Pointer Leaved is not raised when the touch moves outside the bounds of the button, both when the touch begins inside the button and when it begins outside, is moved in, and then is moved back out. Visual state fails to change in both cases.
• Firefox: Pointer Leaved is not raised when the touch starts outside the bounds of the button, is moved in, and then is moved back out. Visual state fails to change. When the touch starts inside the button and moves out, Pointer Leaved is not raised until the touch is released, meaning that only one event is raised even though the pointer might enter and exit the button multiple times, though visual state does correctly change between pressed and not pressed when starting inside the button.
• Edge and Chrome: Pointer Capture Lost is raised twice when touch occurs and is then moved, regardless of whether or not it leaves the bounds of the button, and will not be raised when the button is released. (If the button is touched and then released without movement Pointer Capture Lost is raised correctly.) Firefox: Pointer Capture Lost behaves correctly.

====================================

Android Emulator API 28 (Touch only)

Hover:

• Tapped is raised no matter how long you hold it.
• Double Tapped is raised no matter how long you hold the initial tap.
• Pointer Released is not raised when starting the touch outside of the button's bounds and moving into its bounds before releasing.
• Pointer Entered is not raised if you begin the touch outside of the button's bounds.
• Pointer Exited is not raised if you begin the touch outside of the button's bounds.

Press:

• Tapped is raised no matter how long you hold it.
• Double Tapped is raised no matter how long you hold the initial tap.
• Pointer Released is not raised.
• Pointer Entered is not raised if you begin the touch outside of the button's bounds.
• Pointer Exited is not raised if you begin the touch outside of the button's bounds.

Release:

• Tapped is raised no matter how long you hold it.
• Double Tapped is raised no matter how long you hold the initial tap.
• Pointer Entered is not raised if you begin the touch outside of the button's bounds.
• Pointer Exited is not raised if you begin the touch outside of the button's bounds.

==========================

Skia/Gtk Windows using /dev/dr/runtimeUITests

UPDATE: I tested this against the current Skia/Gtk Windows and the behavior is very different than the behavior when using /dev/dr/runtimeUITests, which is PR #7845 . A brief check showed that the touch visual state getting stuck in pressed seems to rarely occur with the current code. There are some other issues that exist with the current code that don't exist with the #7845 changes. I'll do a full test of each later today and report the findings in a new comment here. #7845 shouldn't be blocked by this since it fixes #7811 (scrollbars and scrollviewer not working). Just noting that it changes other behavior such as buttons (mouse and touch). I'll add a comment on #7845 if my tests show that it broke something important as far as mouse input goes.

Hover Mouse:

• Double Tapped is raised no matter how long you hold the initial tap.
• Click is also raised when exiting the button (maybe a control template issue?)
• Pointer Released is not raised when starting outside of the button's bounds and moving into its bounds before releasing.
• Pointer Entered is also raised when exiting the button's bounds.
• Pointer Exited is raised twice when exiting the button's bounds.

Hover Touch:

• Tapped is not raised on the first touch but the visual state remains pressed. Subsequent touches raise tapped but continue to keep the pressed visual state. Long touches in this state correctly do not raise tapped but keep the visual state and allow continued short touches to raise tapped while keeping pressed visual state. A touch outside of the button's bounds changes the visual state to not pressed and correctly do not raise tapped but a new touch on the button repeats the not raised but visual state goes to pressed, etc., behavior.
• Double Tapped is not raised properly. The first tap puts the button into pressed state. A second tap immediately following does not raise double tapped and keep pressed state. A tap after that raises double tapped regardless of how long a delay there is and keeps pressed state. From there on, every second tap will raise double tapped regardless of delay and visual state remains pressed. Tapping outside the button sets its state back to unpressed and subsequent taps repeat the behavior cycle (first tap into pressed, second no event raised, third raises, etc.).
• Click correctly raises when the button is tapped but leaves it in the pressed visual state. A subsequent tap on the button does not raise click. A touch outside that continues into the button's bounds will raise the event however it will also be raised on exiting. It correctly raises when beginning a touch outside and moving inside but releasing the touch while inside will leave the button in pressed state (but correctly does not raise click). In this pressed state it will not raise click events when tapping the button but will raise when the touch starts outside in the same pattern as above with the first tap and release leaving it in the pressed state.
• Pointer Pressed raises correctly but leaves the visual state in pressed state. The event will continue to raise correctly but the pressed visual state remains. A touch outside will clear it unless the touch moves into the button area before being released, in which case it will briefly switch back to unpressed before switching back to pressed. It correctly does not raise the event and will correctly switch visual states as the touch is moved into and out of the button's bounds but if the touch is released inside the button's bounds it remains in the pressed visual state.
• Pointer Released will correctly raise if the touch begins inside the button and is released without moving out of the button but will leave the button in the pressed visual state. Subsequent touches that begin and remain in the button also correctly raise but the visual state continues to be pressed. Any touch that starts in the button, leaves, then returns before release does not raise the event but does leave the button in the pressed visual state. Any touch that starts outside the button and moves in before being released does not raise but does leave the button in the pressed visual state.
• Pointer Entered will correctly raise if the touch begins inside the button and is released without moving out of the button but will leave the button in the pressed visual state. Subsequent touches that begin and remain in the button will not raise the event. A subsequent touch that begins in the button then exits will reset the visual state to not pressed and will not raise the event but if that touch continues and enters and exits the button then the event will be raised both on entering and exiting and will sometimes be raised multiple times for entrance and exit without any correlation (e.g. there might be one entrance raise but two exit raises or vice versa). That is least likely to happen if moving very slowly but even then it will still happen occasionally. A touch that begins outside and enters will properly raise and if the touch is then released while still in the button the event will correctly not be raised but the button will remain in the pressed visual state and it will then behave the same as if te touch had begun inside the button and been released without moving out.
• Pointer Exited will not raise if the touch begins in the button and is released without moving out but will put the button into a pressed visual state that persists. Subsequent touches that begin and remain will also not raise the event and will maintain the pressed state. The first touch outside the button after that will put the button back into an unpressed state and will raise the event when released if it is released without moving or immediately upon movement if movement occurs before releasing. If that movement ends inside the button then the button will go into the pressed visual state but will not raise the event. If the button is not in the pressed state and a touch begins outside the button, moving in will incorrectly raise the event, often twice and sometimes even more, and moving back out will raise the event, which is correct, except that it will often raise it multiple times.
• Pointer Capture Lost behaves correctly except that if you release the touch inside the button then it will remain in the pressed visual state.

Press Mouse:

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press. It is also raised if you move the pointer on the first tap as long as you return it to the approximate location where the tap began before releasing it and pressing again to trigger the double tapped event.
• Pointer Entered is raised, sometimes twice, when moving the pointer outside of the bounds of the button; it is more likely to occur twice if moving the pointer quickly rather than very slowly.
• Pointer Exited is raised up to three times when moving the pointer outside of the bounds of the button and I think I know why. If the pointer moves over the button's text content then moving it out of that will raise the event. Regardless of whether you moved it over the text, if you move the pointer to the edge of the button it will raise (again), presumably because you've exited the content area and have entered the border. Lastly, when you exit the button completely it will (correctly) raise. In otherwords it is raising the event whenever some element inside the button is exited rather than only raising it when the pointer completely exits the button.

Resolving the incorrect raising of events based on entering/exiting internal elements of a button in Skia and its failure to change visual states correctly for touch input will likely resolve many of the behavior and conformance issues so I'm stopping at the Press Mouse Pointer Exited test for now since further testing will just continue producing those issues (possibly masking other issues in the process). (Note: As stated above, I'm going to do full tests of Skia/Gtk using the current code and the branch in PR #7845 to see what changed between the two. I will likely also do brief testing of Skia/WPF to see if there are any differences between it and Skia/Gtk).

[jeromelaban]

/cc @dr1rrb

[mikebmcl]

This took longer than I thought it would, but I finished testing Skia/Gtk Windows (native not WSL) for current versus the incoming changes in #7845 . I mention it at the end of the notes but since it's rather important I wanted to mention it here too.

I did not do comprehensive testing of Skia/Gtk WSL or Skia/Wpf but I did test them for two specific events where the Skia/Gtk Windows behavior ranged from slightly wrong to outright bizarre and it turns out that they both are very close to conforming to UWP's behavior.

They both have the same problem that I mentioned in a comment on #7845 and both seem to exhibit the same visual state change issues I observed with Skia/Gtk Windows, but my guess is that most or all of the touch input issues that appeared in Skia/Gtk Windows don't exist for Wpf and for Gtk WSL (Wayland-based so I don't know if Gtk on X11 would behave like WSL or like the Gtk Windows).

Also, I discovered that UWP's behavior for various events differs sometimes if there's a mouse right-click rather than a left-click. This wouldn't be notable except for the fact that there are events that are not raised for left-click but are raised on a right-click. So it's not simply a case of buttons ignoring right click pointer events. I only discovered this when testing against #7845 and did not go back and test against the existing code. So the notes for right click behavior are only in the second section of results.

=========

Skia/Gtk Windows 11 Pro Version 10.0.22000 Build 22000 using uno master as of commit 4a63fa2

Note: Any mention below of the "yellow rectangle" or "yellow rectangle inside the button" or anything similar means the portion of the IsHitTestVisible="True" Border (which has a Gold SolidColorBrush as its Background) that is inside the Button being used for the test, including the part that overlaps the IsHitTestVisible="False" Border (which has a BlueViolet SolidColorBrush Background). If a "purple rectangle" or something similar is mentioned, then it means the portion of that BlueViolet Border that is inside the button that does not overlap the "yellow rectangle". Any portion of either of those borders that is outside the button should be considered as behaving the same as everything else outside the border; if there is some reason that it does behave differently then that will be explicitly noted in a way that distinguishes it from the part that is inside the button. Also, any mention of starting, ending, entering, or exiting the button always means a portion of the button that is not within the "yellow rectangle". Button behavior that occurs inside the "purple rectangle" was generally found to be identical to behavior in other, non-"yellow rectangle" parts of the button. Because of that, most test results below were not tested specifically for purple rectangle behavior unless otherwise noted.

Note: In the tests, when a button becomes "stuck" in a pressed visual state, I sometimes tested to see if tabbing to other controls would reset it. I did not test this consistently but every time I tested it, tabbing did not reset the button back to the unpressed visual state that it should have been in. Sometimes I mention that I tried tabbing. The absence of any note about tabbing should not be taken to mean that I tried tabbing and it reset the control to an unpressed state.

Hover Mouse:

General note: At times moving the pointer into the button does not trigger a visual state change to pressed. This only seems to occur when the mouse is moved rapidly into the button's bounds. When this occurs, moving it out may trigger a visual state change to pressed but if so it will then change to unpressed; it will not become stuck in pressed state.

General note: At times moving the pointer out of the button when it is in pressed visual state will not trigger a visual state change to unpressed. This only seems to occur when the mouse is moved rapidly out of the button's bounds. When this happens it will remain in the pressed state until moving the pointer back into the button then moving it slowly out again. The exact speed where it does and does not occur can make it seem arbitrary if the movement speed is near that speed that causes it to become stuck in a pressed visual state. If stuck, it will not switch back to unpressed by clicking outside of the button no matter how many times you click. It will not switch if you move the pointer over another button or click on the hamburger button to get the list of tests to show. It will not switch if you minimize the window then restore it. It will not switch if you maximize then restore. It will not switch if you use touch input outside of the button. It will not switch if you tab through the various controls including tabbing to the button that is stuck and then tab away from it to another control. It will not switch if you change to a different window then change back.

General note: If the pointer moves into the button's bound inside the yellow rectangle that is hit test visible (and thus should block notifying the rectangle) it will correctly block notifications even if the becomes stuck in a visual state. However after moving the pointer into the rectangle somewhere other than in the yellow rectangle, the visual state will remain the same no matter how many times you cross the yellow rectangle or at what speed. Additionally it will not switch states when moving out of the rectangle within the bounds of the yellow rectangle no matter what speed you move the pointer. Basically, it obeys hit testing if it enters the yellow rectangle first but ignores it for the yellow rectangle if it enters the button first.

General note: A note will be added for a specific test if that test does not exhibit the above visual state issues; in the absence of a note assume that the test exhibited the issues. Unless otherwise noted, these issues do not seem to impact the behavior of the test. For example, tapped works correctly regardless of whether or not it gets stuck in the pressed visual state or fails to switch to the pressed visual state.

• Double tapped is raised no matter how long you hold the initial click.
• Click is raised when moving the pointer outside of the mouse button unless the movement out is fast.
• Pointer Pressed works properly including not being raised when a press occurs over the yellow rectangle; it otherwise displays the same issues with the yellow rectangle described above.
• Pointer Released is not raise when the click begins outside of the button (including within the yellow rectangle inside the button) and is then released inside the button.
• Pointer Entered is not raised when moving rapidly into the button. It is not raised when exiting from the yellow rectangle into the button. It is raised when exiting the button unless exiting rapidly (in which case it will also become stuck in the pressed visual state if it was in that state when in the button, which is expected based on the rapid movement visual state behavior described above).
• Pointer Exited is not raised when rapidly exiting the button. It is not raised when moving from the button into the yellow rectangle nor if you then move outside of the button while still in the yellow rectangle. (n.b. Pointer Capture Lost works properly.)

Hover Touch:

General note: The button will get stuck in pressed state sometimes, seemingly when a touch begins outside the button, is moved into the button, then is released while still in the button. Tapping and releasing the button does not switch back to not pressed nor does tapping outside the button. Tapping outside the button, moving in, then moving out and releasing will return the button to not pressed. It will not change to not pressed if the tap begins inside the button then moves out however if the tap begins inside the button, is dragged over the yellow rectangle inside the button, and is then moved out of the button it will switch to not pressed.

General note: The navigation buttons need to be pressed twice when using touch input. The first touch switches them to the pressed state but does not result in the bound command being executed. The second touch switches back to unpressed and the command is executed. The navigation buttons are in the default ClickMode, ClickMode.Release.

• Click is not raised when tapping directly on the button.
• Pointer Pressed is not raised immediately when tapping the button but instead is raised either when releasing or when moving the touch outside of the button's bounds.
• Pointer Released is not raised when the touch starts outside of the button.
• Pointer Entered is not raised when tapping on the button. It is not raised when beginning the touch in the yellow rectangle within the button and moving directly out of it into the button nor when entering the yellow rectangle inside the button from the button and then exiting back into the button. It is raised when exiting the button (except into the yellow rectangle within the button).
• Pointer exited is not raised when exiting from the button into the yellow rectangle within the button.

Press Mouse:

General note: The sticking of visual state behavior for hover mouse does not seem to be the same for press mouse. Notes will be made in each test if there is any visual state problem.

• Double Tapped is raised no matter how long you hold the initial click.
• Pointer Entered is raised when exiting the button. It is not raised when entering the button from the yellow rectangle inside the button.
• Pointer Exited is not raised when the mouse is moved out rapidly. It is not raised when exiting into the yellow rectangle inside the button.

Press Touch:

General note: If a tap happens it will put the button into the pressed visual state and keep it there. Tapping again anywhere will switch the button back to unpressed except if it is a tap outside the button that is moved into the button before being released (in which case it stays in the pressed visual state).

• Double Tapped is correctly raised with a fast first tap and release followed immediately by a tap. However holding a tap for more than a fraction of a second results in the button switching between the pressed visual state and the unpressed visual state as per the note above. However when this happens, a second tap on the button does not raise the event; it simply puts the button into the unpressed visual state. If that is followed by another tap on the button, the event will be raised and the button will once again become stuck in the pressed visual state. The amount of time between taps does not matter. A tap that sticks the button in the pressed state followed by two taps outside the button followed by a tap on the button will trigger the event (the first tap outside will clear the pressed state but might leave the button in the hover over state that should only be possible with mouse input). I did not try every combination of that tapping outside the button but there are situations where it does not occur. However it will always occur if the first thing you try on this test is that tap the button, tap twice outside, then tap the button again sequence. Except if the two taps outside the button are done rapidly in which case the behavior does not manifest. There does seem to be a pattern to getting it to trigger if a double tap has already begun but describing it is difficult. It's not random and it's not time related; it seems to be connected to the button's internal state.
• Click not raised when the button is pressed. Instead it is raised either when the touch is released or when it is moved outside the bounds of the button.
• Pointer Pressed is correctly not raised if the button is quickly tapped, though it will get the visual state bug described above. However if you touch the button, hold for at least a small bit of time, and then either release the touch or move it outside the bounds of the button, pointer pressed will be raised.
• Pointer Released is not raised when touching, holding for at least a small bit of time, and releasing.
• Pointer Entered is raised when exiting the button unless the movement out is fast. It is not raised if the button is tapped. It is not raised if the touch begins outside the button and is moved in rapidly. It is not raised when the touch begins inside the yellow rectangle within the button regardless of how fast the movement into the button occurs.
• Pointer Exited is not raised when tapping on the button and releasing within the button. It is not raised when moving from the button into the yellow rectangle within the button. It is not raised if the touch is moved rapidly out of the button.
• Pointer Capture Lost behaves incorrectly. It is not raised when the timer expires nor is it raised when the touch is released. If the first touch on the button puts it into a pressed visual state then a second touch on it will put it back into an unpressed visual state and each touch on it after that will raise the event except for a touch that is held for more tha a brief amount of time which does not raise the event but will not prevent a subsequent quick touch from raising the event. When it enters this cycle, each touch will cause the button to alternate between the hover visual state and the pressed visual state.

Release Mouse:

• Double Tapped is raised any time two clicks occur on a button no matter how long the first is held for nor how much time passes before the second press provided that the pointer isn't moved any significant amount.
• Click sometimes is not raised if the pointer is moved outside of the button and then back in but other times it is (correctly) raised. It seems that if the pointer is moved quickly outside the button then is moved slowly back in the event will correctly be raised but when moving out slowly or moving out quickly and moving in quickly it will not be raised.
• Pointer Entered is raised when moving the pointer out of the button slowly. It not raised when moving the pointer into the button quickly.
• Pointer Exited is not raised when moving the pointer out of the button quickly and the button will remain in the hover visual state. Moving the pointer into the button quickly will not switch its visual state to hover however if you then move it out slowly the button will switch to the hover state then back to the unpressed (correct) state and will correctly raise the event.

Release Touch:

• Tapped is raised correctly however each tap will switch the button from unpressed state to pressed state or pressed to unpressed. If it is in pressed visual state, tapping outside of the button will return it to unpressed.
• Double Tapped works correctly for a quick tap followed by a second tap. If first tap is slow, the button will switch to a pressed visual state and remain. A second tap after that will return it to unpressed but will not raise the event, however if that second tap is followed quickly by a third tap then the event will be raised (and if that tap is not released quickly the button will remain in pressed visual state when releasing it).
• Click will not be raised on the first tap and the button will switch to the pressed state. A second tap will raise the event and switch the button back to unpressed. A touch that is held for any significant amount of time will not raise the event nor switch its visual state. A touch that exits the button then returns into it before being released will not raise the event. A long tap will not raise the event or switch the visual state however if it is then followed by a quick tap, the event will then be raised and the button will switch to the pressed visual state.
• Pointer Pressed will be raised if the touch is held for at least a small bit of time before being released. Quick taps will cause the button to switch between pressed and unpressed visual states but will (correctly) not raise the event.
• Pointer Released is not raised when a touch is held for at least a second and then released. Quick taps will cause the button to switch between pressed and unpressed visual states but will (correctly) not raise the event.
• Pointer Entered is not raised if the button is tapped. It is not raised if the touch moves quickly into the button and stops within the yellow rectangle within the button but will be raised when exiting the button if proceeding to exit on the buttons left side passing through the purple rectangle within the button but only upon fully exiting the button.
• Pointer Exited is not raised if the button is tapped. It is not raised if the touch moves out of the button quickly and if the touch moved in slowly causing the button to switch to hover visual state it will remain in hover visual state.
• Pointer Capture Lost is not raised if the button is pressed and held for a few seconds before releasing.

General note: For all of the touch tests above, pressing and holding for 2+ seconds brings up what appears to be an empty context menu. Where events do not occur that should have, this may be the reason. It is also possible that this stops events from being raised that otherwise would have been improperly raised.

================================================

Skia/Gtk Windows 11 Pro Version 10.0.22000 Build 22000 using branch /dev/dr/runtimeUITests as of commit 139cdda9

General Note: Unless otherwise stated, all events that are invoked due to movement into or out of a control suffer from an issue where whenever the pointer moves out of a part of the button into its container (e.g. from the Content to the ContentPresenter), the event is raised. Also, the first time the pointer moves into a part of the button the event will (correctly) not be raised but after that each time it enters that part the event will be raised (in addition to being raised whenever it exits).

This only affect movement within the parts of the button. Movement out of the button or into the button only invokes the event if it is supposed to be invoked. This effects Click for ClickMode.Hover and PointerEntered and PointerExited for all ClickMode enumerators. The one exception is that for PointerEntered and PointerExited, if the movement into or out of the button is very fast, then the event will only be raised at the time it should be raised. In the case of touch input that begins inside a button, if movement before releasing the touch is intended then the touch must be rapidly moved out of the button immediately after it begins to avoid the chance of the event raising due to movements between parts of the button.

If the events that are susceptible this conform to UWP behavior in all other regards then no note will be made about the event specifically, e.g. for ClickMode.Hover with Mouse input, Click, PointerEntered, and PointerExited all behave identically to UWP except for this issue and so no mention of them is made below.

General Note: I did not test right-click behavior for the previous set of tests but upon discovering that right click was raised during one of these tests when a left click did not raise the event I decided to test right clicks here. I will only report when the Skia behavior differs from UWP or when right click behaves differently than left click. If a behavior difference is noted without any mention of platform, then the behavior difference was the same on UWP and Skia.

Hover Mouse:

• Tapped is not raised on right click.
• Double Tapped is raised no matter how long you hold the initial tap. It is also raised no matter how much times passes between the two taps provided that the pointer was not moved any significant amount. On UWP, the event is not raised if there is a right click between the left clicks or when either or both of the clicks are right clicks. On Skia, the event is raised when one or more right clicks occur between the left clicks but as with UWP a right click never raises the event.
• Pointer Released is not raised when starting outside of the button's bounds and moving into its bounds before releasing.

General note: The same touch and hold for 2+ seconds bringing up an empty context menu behavior occurs with this branch. This applies to all touch tests (Hover, Press, and Release).

General note: Unlike with previous event tests, most of these touch tests are split up into multiple paragraphs because they have a number of behaviors that vary depending on multiple factors, e.g., there are places where the behavior is different for a touch that begins outside the button, moves into the button, then moves into the yellow rectangle inside the button versus a touch that begins outside the button, moves into the button, then moves outside of the button without going into the yellow rectangle inside the button. In general, if the behavior of entering the yellow rectangle inside the button and exiting the button are the same, it will just be noted as exiting the rectangle. The same for entering. I can't guarantee that I remembered to test entering/exiting the yellow rectangle for every specific case. So there may be a few cases where there is different behavior for the yellow rectangle and outside the button but the difference isn't noted because I forgot to test it or thought I did but made a mistake. This applies to all touch tests (Hover, Press, and Release).

Hover Touch:

• Tapped is not raised on the first touch but the visual state remains pressed (the touch can be short or long). Subsequent touches raise tapped but continue to keep the pressed visual state. Long touches in this state correctly do not raise tapped but keep the visual state and allow continued short touches to raise tapped while keeping pressed visual state. A touch outside of the button's bounds changes the visual state to not pressed and correctly does not raise tapped.

• Double Tapped is not raised properly. A quick tap followed immediately by a touch does not raise the event and the visual state never changes on the first tap.

If the first touch is not rapid, then the first tap puts the button into pressed state. A second tap following does not raise double tapped and keeps the pressed state. A tap after that raises double tapped regardless of how long a delay there is and keeps the pressed state. From there on, every second tap will raise double tapped regardless of delay and visual state remains pressed.

Tapping outside the button sets its state back to unpressed and reset the button's behavior to its initial state. However if the tap outside is in the yellow rectangle within the button then the button visual state will switch back to unpressed however the next touch inside the button might raise the event, presumably depending on the internal state that keeps track of double tap.

If the button is in a pressed visual state and a tap happens somewhere in the button other than where the previous tap occurred, the button will remain in the pressed visual state but will not raise the event but instead will begin a new cycle with that as the point that must be pressed to get double click events to raise.

Whenever the event is raised, it is always raised on release rather than press.

If a tap is held then it will not raise the event, will keep the pressed visual state, and the button will not raise the event until the third quick tap after the tap that was held.

• Click is not raised immediately when a touch begins inside the button and does not move significantly before being released but instead is raised when the touch ends. The button switches to the pressed visual state upon release and remains in that state.

It is raised when exiting the button if it begins inside the button and is moved out. The visual state will switch to pressed and then back to unpressed at the moment that the touch exits the button.

If a touch is released inside the button, leaving it in the pressed visual state, then subsequent taps on the button without any subtantial movement do not raise click, even if the subsequent tap is in a different part of the button, unless the touch point is right at the edge of the button but still within it. It is possible that this edge of the button behavior is actual due to motion being registered from the ContentPresenter into the Border since touch input is not as precise as mouse input due to the size of a person's fingertip.

When the button is stuck in the pressed visual state, tapping outside the button will reset its visual state to unpressed and the event will (correctly) not be raised unless the touch then proceeds to enter the button.

A touch that starts inside the button and moves into the yellow rectangle inside the button or starts outside and moves rapidly through the button into the yellow rectangle raises the event upon crossing into the yellow rectangle rather than when the touch begins/enters the button and the button will change to the pressed state then back to unpressed when it crosses into the yellow rectangle.

• Pointer Pressed is raised when leaving the button, either by releasing the touch or moving it out of the button, rather than when the touch begins. If the touch is released inside the button, the button will remain in the pressed visual state and will stay in that state until a touch occurs outside the button or a touch that begins inside the button is moved out of the button.

• Pointer Released is not raised when any significant movement of the touch is made within the button before releasing or when the touch is moved out of the button then back in before releasing. Releasing the touch inside the button leaves the button stuck in the pressed visual state.

It is properly raised when no significant movement occurs but leaves the button in the pressed visual state. Subsequent taps will continue to properly raise the event but the button will remain in the pressed state.

It is not raised when the touch starts outside the button and moves in before being released. The button will be left in the pressed visual state.

• Pointer Entered appears to behave identically to Click, which makes sense since for ClickMode.Hover they are functionally identical.

• Pointer Exited will not raise if the touch begins in the button and is released without moving out but will put the button into a pressed visual state that persists. Subsequent touches within the button also will not raise the event and the button will remain in the pressed state. However, once it is in this state, regardless of whether it was pressed just the first time or multiple times, then a touch outside the button will raise the event and return the button to the unpressed visual state.

A rapid movement into the button from a touch that begins outside of it will (correctly) not raise the event but if the touch is then released without any substantial movement the event will not be raised.

• Pointer Capture Lost behaves correctly except that if you release the touch inside the button then it will remain in the pressed visual state.

Press Mouse:

• Tapped is not raised on right click.

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press. On UWP, the event is not raised if there is a right click between the left clicks or when either or both of the clicks are right clicks. On Skia, the event is raised when one or more right clicks occur between the left clicks but as with UWP a right click never raises the event.

It is raised no matter how much time passes between the first tap and the press that follows.

• Click is not raised on a right click.

• Pointer Pressed does not switch to unpressed visual state when moving into the yellow rectangle but instead remains in that state until either releasing the pointer or moving it outside the bounds of the button. Pointer Pressed is raised on right click.

• Pointer Released behaves correctly except that it is not raised on right click whereas on UWP it is raised on right click.

• Pointer Capture Lost is not raised on UWP and Skia when right clicking.

Press Touch:

• Tapped is not raised on the first tap and release but the button switches to the hover visual state. Each subseqent touch will raise the event and the button will switch between the pressed visual state and the hover visual state. If the button is in unpressed visual state, a touch that begins outside the button, moves into it, and is released behaves the same as a tap on the button when it is in unpressed visual state (switches to hover then subseqent taps raise and change visual state).

• Double Tapped does not raise correctly. It never raises in the way that it does for UWP. Its behavior is difficult to describe. For each of the following the test that produced the described result began upon navigating to the double tapped test so that the button would be in its default state when beginning.

A first tap puts the button into hover visual state. The next tap will put it into pressed state but will not raise the event. The tap after that (i.e. the third tap) will raise the event and the button will remain in pressed visual state. From this point every other tap will raise the event and the visual state will switch between hover and pressed on each tap.

A first tap puts the button into hover visual state. The next tap will put it into pressed state but will not raise the event. A tap outside the button will put it back into unpressed visual state. But if the button is then tapped at approximately the same place as the previous two taps on the button the event will be raised. If the tap is in a different location within the button then it will not be raised. Subsequent taps outside then inside the button will sometimes result in the event being raised when tapping in the button, but I'm unable to find a pattern that reliably triggers this so I am simply noting that sometimes the event will be raised when tapping inside the button even though the previous tap was outside the button. This behavior can also occur with the previous consistent taps within the button if a tap is made outside the button at some point.

If the first tap is held, the button will be put into the hover state. Subsequent long taps in the button will not have any discernable effect but short taps will raise the event at the times described in the first test as if the subsequent long taps never occurred. The exception is that after the short tap that raises the event occurs, a long tap will switch the button back to hover state with the same subsequent behavior as if it was a short tap rather than a long tap.

If the first touch begins outside the button, is moved into the button and released, the button will switch to hover visual state and will behave the same as if the the first touch was a tap within the button.

A first tap inside the button followed by a second tap inside the button (the same as the first test) followed by a tap and hold that is then moved outside of the button before release will not raise the event but if the next tap is in the button at approximately the same location as the previous touches, the event will be raised.

This is not a comprehensive list of all behaviors since all permutations of short and long touches that do or do not involve movement into or out of the button would take a very long time and would probably not provide additional value beyond the behavior already documented.

• Click appears to behave substantially the same as tap with some exceptions noted below.

The event will be raised if the touch begins in the button and is moved out of the button without holding it long enough to bring up the context menu. This happens no matter what state the button is in before doing it. Each time this is done the event will be raised such that doing this multiple times in a row will raise the event every time. If the touch is held long enough to bring up the context menu then the event will not be raised if the touch is then moved out of the button.

• Pointer Pressed is raised on release when the touch is held for a bit of time before releasing (long enough to bring up the empty context menu). It is also raised upon moving the touch out of the button if instead of releasing it within the button after the context menu appears the touch is then moved out of the button.

• Pointer Released is not raised when the touch is pressed and released within the button regardless of how long it is held.

• Pointer Entered is not raised when the touch enters the button but instead is raised when the touch stops inside the button or when the touch exits the button if the touch does not stop in the button but instead is continued until after it exits the button.

If the button is in the unpressed state then the event will be raised when the button is tapped, including if the touch is held before releasing, but the event is not raised for subsequent taps within the button but short taps will switch the visual state between hover and pressed.

• Pointer Exited is raised when stopping within the button if the touch starts outside the button, moves quickly into it, and then stops rather than when the touch is released. The move quickly in is intended to avoid the movement within the button issue; the behavior would likely be the same if the movement was slow if the movement within the button issue did not exist.

It is not raised when a touch begins within a button and is released.

• Pointer Capture Lost is not raised programmatically. It is also not raised if the touch is held long enough to bring up the context menu and is then released, either inside the button or after moving the touch out of the button before releasing.

Release Mouse:

• Tapped is not raised on right click.

• Double Tapped is raised when a long tap (press, hold 1+ seconds, release) is followed immediately by a press. On UWP, the event is not raised if there is a right click between the left clicks or when either or both of the clicks are right clicks. On Skia, the event is raised when one or more right clicks occur between the left clicks but as with UWP a right click never raises the event.

It is raised no matter how much time passes between the first tap and the press that follows.

• Click is only raised sometimes when exiting the button and then re-entering it before releasing. It will correctly be raised if all movement is within the mouse, though. Additionally, testing to try to return the pointer as close to its original position as possible before releasing after exiting and entering did not cause the event to be raised with any consistency and the event was sometimes raised when the pointer was in a completely different location when released than it was when the click began when exiting and entering. So it doesn't seem to be location based. The closest I got to consistently reproducing it was to move the pointer out of the button extremely fast and then moving it back in extremely fast and instantly releasing the mouse button. How long it stayed outside the button didn't seem to matter.

It is not raised on right clicking.

• Pointer Pressed is raised on right click.

• Pointer Released is raised on right click on UWP but not on Skia.

• Pointer Capture Lost is not raised on right click.

Release Touch:

• Tapped is not released on the first tap but the button is put into the hover visual state and every tap on the button after that will raise the event and switch the visual state between hover and pressed. Any tap outside the button will return the button to unpressed state and (correctly) not raise the event, effectively returning it to its initial state. If the button is in an unpressed state, beginning a touch outside the button and moving it into the button before releasing will put it into the hover state and it will then behave the same as if that had been an initial tap rather than moving the touch in and releasing it.

• Double Tapped appears to behave the same as it does in ClickMode.Press after doing several of the tests I did for that so I'm not going to fully retest it and report all the results again since it seems like they would be identical.

• Click is raised for each short tap but the first short tap puts it into the hover visual state then each subsequent tap switches between pressed and hover visual states. A touch and hold that brings up the context menu does not raise the event when releasing the touch. A touch that leaves the button then enters again before being released does not raise the event unless the movement out and back in is very quick with no time spent lingering outside of the button.

• Pointer Pressed is raised on release when the touch is held for a bit of time before releasing (long enough to bring up the empty context menu). It is also raised upon moving the touch out of the button if instead of releasing it within the button after the context menu appears the touch is then moved out of the button.

• Pointer Released is not raised when the touch is pressed and released within the button regardless of how long it is held. NOTE: The text for Button_Events_Release is missing a note that UWP exhibits that behavior. The text should be identical to the text of Pointer Release in Button_Events_Press because the UWP behavior is identical to that.

• Pointer Entered is not raised when the touch enters the button but instead is raised when the touch stops inside the button or when the touch exits the button if the touch does not stop in the button but instead is continued until after it exits the button.

If the button is in the unpressed state then the event will be raised when the button is tapped, including if the touch is held before releasing, but the event is not raised for subsequent taps within the button but short taps will switch the visual state between hover and pressed.

• Pointer Exited is raised when stopping within the button if the touch starts outside the button, moves quickly into it, and then stops rather than when the touch is released. The move quickly in is intended to avoid the movement within the button issue; the behavior would likely be the same if the movement was slow if the movement within the button issue did not exist.

It is not raised when a touch begins within a button and is released.

• Pointer Capture Lost is not raised if the touch is held long enough to bring up the context menu and is then released, either inside the button or after moving the touch out of the button before releasing.

==================

Important: Skia/Gtk running on WSL and Skia/Wpf exhibit at least some behavioral differences from Skia/Gtk Windows. They still exhibit the raising Enter/Exit events whenever moving over internal parts of the control behavior. As an example of different behaviors:

Skia/Gtk WSL and Skia/Wpf Hover Touch properly raises the Tapped event on the first touch and otherwise conforms to UWP behavior except that the first touch puts it into the pressed visual state and it remains there on subsequent taps.

Skia/Gtk WSL and Skia/Wpf Press Touch Double Tapped does not raise until the release of the second tap but otherwise seem to conform to UWP. Which is rather nice to discover given how strange Skia/Gtk Windows behaves.

[dr1rrb]

Hi @mikebmcl , really impressive investigation. Some of those are somehow known (https://github.com/unoplatform/uno/blob/master/doc/articles/features/pointers-keyboard-and-other-user-inputs.md#known-limitations-for-pointer-events - Some was fixed, docs needs to be updated), and fixing all of them at once would require a massive work.

For instance enter/exit are known to be problematic on Android and iOS which are doing what I call "implicit capture" (once pressed, a pointer is always routed to the same element, not mater if pointer was move above another element, even if not captured by the app). To fix those it would require that we do the pointer dispatch in managed code, and go in native only when we reach a non managed element.

So for now we are only trying to get as close as possible to UWP behavior.

I've look into test that you are adding in https://github.com/unoplatform/uno/pull/7892 and I noticed 2 majors issues:

• Tapped being raised no matter the duration: I've fixed it in commit https://github.com/unoplatform/uno/pull/7892/commits/d4c5578de1052a86e8ed5283372ea58a49ec5438 that I've pushed on your branch (I've also rebase you branch on uno/master and I will merge it as soon as possible)
• On WASM the PointerExited is still not always raised properly, especially when pen and touch are leaving the screen. I've already an issue in my backlog for that https://github.com/unoplatform/uno/issues/2905 that I expect to fix during this week.

So even if I would love to be able to fix all issues you mentioned above in order to be 100% compliant with UWP behavior, for now I would recommend that we focus on issues that are blocking (or even just annoying) in projects. Slowly we are getting even closer :)

GitHub

uno/pointers-keyboard-and-other-user-inputs.md at master · unoplatform/uno

Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported. - uno/pointers-keyboard-and-other-user-inputs.md at master · unoplatform/uno