Bug: Right Mouse Button Release event never gets sent

[RobWalt]

A while ago, we discovered some weird behavior with the bevy engine when compiling to wasm.

When opening the context menu in the browser, things behaved weirdly after that. I opened an issue on the bevy UI library we are using (link above). After some analysis it turned out that the mouse state got stuck since we don't receive a released event when pressing the right mouse button. This in turn blocks the user from using the wasm app at all since inputs are all screwed up.

This issue might be slightly related to #2455 and #2475 but it still seemed distinct enough to open a new issue.

I'll try to get a minimal reproducible example running in the near future which only utilizes winit.

[RobWalt]

To get a minimum reproducing example, just edit the following lines in the examples/web project:

// old, line 78
//log::debug("{:?}", event);

// new
if matches!(event, Event::WindowEvent {
  event: WindowEvent::MouseInput { .. },
  ..
}) {
  log::debug("{:?}", event);
}

Then just run the example as described in the general README.md via

cargo run-wasm --example web

---

I recorded some testing footage. It contains the following two scenarios:

1. The context menu is opened via right click. No Released event is fired until we press the right mouse button anywhere else again.
2. The context menu is opened via right click. Pressing the left mouse button anywhere else fires its Released event which kind of screws up the pairity of Pressed <-> Released events for one button. I think this scenario is also responsible for the issue initially reported here

Additional IMPORTANT notes:

• I noticed that the behavior above mainly happens if the right mouse button is pressed for a certain amount of time (anything longer than a very short click)
• The right mouse button release is correctly fired if I just slightly click the button for a very short time

[RobWalt]

It seems like the reason could be related to the order some events are fired. Here is some further analysis:

If we press the button just slightly, we get the following order of events (oldest events are on the bottom):

It seems like entering the context menu with the cursor counts as a CursorLeft event. If we just click the right mouse button, the cursor hasn't left the window yet, leading to correct handling of the Release event.

If we keep the right mouse button pressed on the other hand, the cursor has time to leave the window as can be seen in the next screenshot

Since we aren't in the window with the cursor any longer, the release event doesn't get fired (the one in the screenshot was fired after an additional click on the window again)

[RobWalt]

It seems very weird to me that the Release event on right click isn't fired on hold down. For the left click it works as expected, even if we leave the window while keeping the button pressed

---

I would be happy to work on a PR for this issue with some rough guidance. If anyone has some general pointers where to look for a fix I would be very happy. I'm currently out of ideas and I don't know winit well enough (yet)

[madsmtm]

Sorry, we don't have a web maintainer atm., so I can't really point you to someone that can help. Though if you end up with a PR that fixes it, I can merge it at some point.

[daxpedda]

I can't reproduce this anymore, probably because of #2662.
Feel free to re-open with a step-by-step guide if you are able to reproduce this.

[RobWalt]

I just tried it out and it is still kind of reproducible. The left mouse button still seems to be stuck when opening the context menu. On the bright side, its state gets reset if the user presses the left mouse button again. So I would consider this as fixed aswell and it's all good from my side!

Thanks for the ping!

[daxpedda]

The left mouse button still seems to be stuck when opening the context menu.

The context menu shouldn't open anymore. Are you using with_prevent_default(false)? I didn't try that.

[RobWalt]

Oh I probably have to wait until the changes are used downstream. I'm happy in any way, but will give feedback once it's changed downstream 👍🏼

[daxpedda]

Would be really nice if you could try the current version on master, so the next version is actually fixed.
You should be easily able to try it out locally by adding the following to your root Cargo.toml file:

[patch.crates-io]
winit = { git = "https://github.com/rust-windowing/winit" }

See the Cargo Book for more information on this.