Skip to content

On Windows, fix bug causing mouse capture to not be released.#1797

Merged
msiglreith merged 2 commits into
rust-windowing:masterfrom
SamRodri:fix_windows_mouse_capture
Dec 15, 2020
Merged

On Windows, fix bug causing mouse capture to not be released.#1797
msiglreith merged 2 commits into
rust-windowing:masterfrom
SamRodri:fix_windows_mouse_capture

Conversation

@SamRodri
Copy link
Copy Markdown
Contributor

  • Tested on all platforms changed
  • Compilation warnings were addressed
  • cargo fmt has been run on this branch
  • cargo doc builds successfully
  • Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • Created or updated an example program if it would help users understand this functionality
  • Updated feature matrix, if new features were added or implemented

Fixes #1796

@maroider
Copy link
Copy Markdown
Member

I tried your changes, and they seem to fix the issue.

@msiglreith msiglreith added the DS - win32 Affects the Win32/Windows backend label Dec 11, 2020
@msiglreith msiglreith self-requested a review December 11, 2020 21:51
@msiglreith msiglreith merged commit 932cbe4 into rust-windowing:master Dec 15, 2020
@maroider
Copy link
Copy Markdown
Member

maroider commented Jan 18, 2021

I must admit that I only tested whether this PR fixed #1796 without checking for regressions. I've now discovered that doing the following seems to cause a deadlock:

  1. Press down one mouse button over the window
  2. Press down another mouse button anywhere, without releasing the first one

maroider added a commit to maroider/winit that referenced this pull request Jan 18, 2021
The issue was caused by calling SetCapture on a window which already
had the capture. The WM_CAPTURECHANGED handler assumed that it would
only run if the capture was lost, but that wasn't the case. This made
the handler to try to lock the window state mutex while it was already
locked.

The issue was introduced in rust-windowing#1797 (932cbe4).
maroider added a commit to maroider/winit that referenced this pull request Jan 18, 2021
The issue was caused by calling SetCapture on a window which already
had the capture. The WM_CAPTURECHANGED handler assumed that it would
only run if the capture was lost, but that wasn't the case. This made
the handler to try to lock the window state mutex while it was already
locked.

The issue was introduced in rust-windowing#1797 (932cbe4).
msiglreith pushed a commit that referenced this pull request Jan 19, 2021
The issue was caused by calling SetCapture on a window which already
had the capture. The WM_CAPTURECHANGED handler assumed that it would
only run if the capture was lost, but that wasn't the case. This made
the handler to try to lock the window state mutex while it was already
locked.

The issue was introduced in #1797 (932cbe4).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DS - win32 Affects the Win32/Windows backend

Development

Successfully merging this pull request may close these issues.

Windows: Mouse capture not released in some cases

3 participants