Opening an UWP flyout two times causes the cursor to jump into the middle of the game window

[SonoSooS]

Type

Other

Bug description

Opening any UWP flyout (like Start Menu or Notifications) two times while the game is focused will cause the cursor to jump into the middle of the game window.

Detailed steps:

• click into the game (so it gets focus)
• do whatever (focus, unfocus, move cursor out of the window, move cursor back into the window, etc.)
• make sure the game is focused, and the cursor is inside the game window
• trigger an UWP flyout (can be via an event, OEM custom input, key combo, etc.)
• do whatever (same as before, but interacting with the UWP flyout doesn't cancel this bug)
• dismiss the UWP flyout (ESC works here, but clicking away also works), but do not move the cursor once the game is in focus again
• do not trigger any pointing device input!
• the game has to be focused, and the cursor has to be inside the game window
• trigger the UWP flyout again
• the cursor will snap into the center of the game window
• the UWP flyout will open

What triggers this bug:

• Start Menu
• Notifications
• WIN+X menu
• WIN+D to show desktop, then WIN+D to restore the windows
  What doesn't trigger this bug:
• ALT-TAB

Raw Input must be on!

Windows 10 version: 1703

Screenshots or videos

No response

Version

2022.501.0-lazer

Logs

runtime.log
performance.log
updater.log
database.log
performance-draw.log
performance-update.log
performance-audio.log
performance-input.log

[peppy]

We are tracking SDL issues at ppy/osu-framework#5126. This is likely one of the ones already being tracked.

If you are serious about it, please also search on SDL's end and test against their master branch and report if it happens there.

[SonoSooS]

I did test SDL2 master (db36664f262bc346aadc5170fdac2d7c6f458ae3) and the newest commit mentioned in #5126 (6c962177272c6a2ce684e4298b40c25ebdd1ac74) using latest release client (2022.501.0), and this issue still occurs with both.

I thought of testing 2021.720.0, and sure enough, I'm unable to reproduce this issue.
After some hunting, this regression seems to occur from 2021.1016.0 (unaffected) to 2021.1028.0 (affected).
Testing with the osu commit of tag 2021.1016.0, I managed to narrow it down between osu-framework tag 2021.1014 and tag 2020.1026.0, eventually tracking it down to commit 0279cc1723885cb1b605007720a7e58162050478, which updated SDL2-CS from 1.0.452-alpha to 1.0.468-alpha, confirming the SDL2 regression.

As for the SDL side, long story short is that I managed to isolate the issue, and I will try to fix it properly and open a PR to SDL. Then if it's merged then I'll notify in #5126.

Important note: do not forget to back up your data folder before testing older versions, otherwise the older versions will completely corrupt all your data, even if they crash before the main window shows up. Guess how I found this out...

[peppy]

thanks for following up. please link any SDL issues you make here for tracking purposes. will cc/ @Susko3 as well since he's been tracking SDL bugs more closely than I am.

Important note: do not forget to back up your data folder before testing older versions, otherwise the older versions will completely corrupt all your data, even if they crash before the main window shows up. Guess how I found this out...

osu! will always backup your database before anything bad happens. you should have a _corrupt or backup folder with a previous version available.

[Susko3]

This should be fixed with ppy/osu-framework#5136 + SDL main.

[Susko3]

I've written up a more detailed bug report about this exact issue and related ones in libsdl-org/SDL#5271, if you're interested.

[peppy]

Right, so the hint being set is important for testing (https://github.com/ppy/osu-framework/pull/5136/files#diff-802f1281748362cec8a6ce40039ebf6ae50bd82897f7d4c0699df24234b7a5e3R434).