Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue with cancelled touch pointers not resetting state correctly #6875

Conversation

marcelwgn
Copy link
Collaborator

Description

When a touch pointer gets cancelled, we expect that there still would be a pointer exited event, however that does not occur. Because of that, when we get pointer cancelled for touch pointers, we should treat this also as a pointer-exited event.

Motivation and Context

Fixes #6863

How Has This Been Tested?

Tested manually.

Screenshots (if appropriate):

@ghost ghost added the needs-triage Issue needs to be triaged by the area owners label Mar 22, 2022
@@ -1070,7 +1070,8 @@ void NavigationViewItem::ProcessPointerCanceled(const winrt::PointerRoutedEventA
// What this flag tracks is complicated because of the NavigationView sub items and the m_capturedPointers that are being tracked..
// We do this check because PointerCaptureLost can sometimes take the place of PointerReleased events.
// In these cases we need to test if the pointer is over the item to maintain the proper state.
if (IsOutOfControlBounds(args.GetCurrentPoint(*this).Position()))
// In the case of touch input, we want to cancel anyway since there is not pointer exited for touch events.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the doc, pointer exited should have been fired for touch as well. Maybe we should just say "we want to cancel anyway".

Or are there 2 code paths that we need to handle, one for cancelling, one for existing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, my comment was not worded entirely correct. So if a pointer is cancelled, in my testing atleast, there won't be a pointer exited. So in the case of touch, we just assume it's gone and we should not stay in the pointer-over mode.

@ojhad ojhad self-requested a review March 23, 2022 21:55
@ojhad ojhad added bug Something isn't working area-NavigationView NavView control team-Controls Issue for the Controls team and removed bug Something isn't working needs-triage Issue needs to be triaged by the area owners labels Mar 23, 2022
@bpulliam
Copy link
Contributor

bpulliam commented Dec 2, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@bpulliam bpulliam merged commit 18a981d into microsoft:main Dec 2, 2022
MartinZikmund added a commit to unoplatform/uno that referenced this pull request Sep 5, 2023
MartinZikmund added a commit to unoplatform/uno that referenced this pull request Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-NavigationView NavView control team-Controls Issue for the Controls team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Long-touching navigation view item would cause the pressed backplate to stay
4 participants