Align Touch/Pen capture semantics with Mouse - #21325
Conversation
It's not so much about third-party code unexpectedly calling |
256dba2 to
fb6e994
Compare
|
updated |
|
You can test this PR using the following package version. |
|
the failing tests look legit, will look into them |
|
though weirdly none seem to be related to pointer or touch |
|
@MrJul I cannot repro the failing integration tests locally (and they do not look like they should be affected by the PR), can you try run it again? |
What does the pull request do?
Removes
Capture(null)fromPointer.Disposable(), expecting callers to call it explicitly with the appropriate source.What is the current behavior?
PenUp and TouchUp are treated as explicit capture loss, resulting in popups closed unexpectedly.
What is the updated/expected behavior with this PR?
Like with mouse, the captures on down and up are marked as implicit. TouchCancel is treated as loss from platform.
How was the solution implemented (if it's not obvious)?
Pointer.Dispose()is now no-op - keepingPointer : IDisposablefor ABI compatibility. Added explicitCapture(null, source)to call sites.Checklist
Breaking changes
The only
Dispose()that was not complemented withCapture(null, source)is inPenDevice.ProcessRawEventforshouldReleasePointer = true, which happens onLeaveWindowandXButton2Up. The former is no-op for mouse too, and the latter is already handled inPenUpit calls.Obsoletions / Deprecations
Fixed issues