Description

When using AbsoluteLayout to implement drag/move behavior via PanGestureRecognizer, the initial pan gesture sometimes fails to start on Windows if the drag begins on the first few pixels of the draggable view (typically near its edge). In this case, PanUpdated is not raised at all.

While debugging the MAUI main branch, I noticed that OnPointerExited in GesturePlatformManager.Windows.cs can fire before HandlePan. This clears _fingers, so _fingers.Count == 0 and no PanGestureRecognizer matches TouchPoints (default is 1), preventing PanUpdated from being triggered. The TouchPoints property default is 1.

If the drag starts more “inside” the control, OnPointerExited does not fire first and HandlePan correctly finds a PanGestureRecognizer with TouchPoints == _fingers.Count, so the gesture works as expected.

Steps to Reproduce

1. Create a page with an AbsoluteLayout.
2. Add a draggable child view (e.g., Border, Frame, Grid) with a PanGestureRecognizer attached.
3. Run on Windows.
4. Start dragging from the first few pixels near the edge of the child view (e.g., top/left border area).
5. Observe that PanUpdated does not fire.
6. Start dragging again but from the center/interior of the child view.
7. Observe that PanUpdated fires normally.

Link to public reproduction project repository

No response

Version with bug

10.0.40

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

I've been using two PanGestureRecognizer, on default, with TouchPoints equal 1 and another, to the same View, with TouchPoints equal 0, doing this, I covered the two scenarios that I've mentioned on the description.

Relevant log output