https://bugs.winehq.org/show_bug.cgi?id=55902
--- Comment #3 from alexandros.frantzis@collabora.com --- Created attachment 75440 --> https://bugs.winehq.org/attachment.cgi?id=75440 Wine log snippets (running with WineX11/Xwayland, GNOME 45.1) for the double-click, double-tap and double-tap with small delay scenarios.
I am able to reproduce the double-tap to maximize problem under GNOME, both with winewayland.drv, but also with winex11.drv/Xwayland when using Wine decorations (i.e., "Allow the window manager to decorate the windows" is *not* ticked in winecfg). This doesn't seem to be a problem with WM decorations, since in that case the WM is handling the taps/clicks on the decorations.
From a quick investigation the issue seems to be that the second tap is never sent by GNOME (neither in the Wayland nor Xwayland case), and the window remains in "move" mode (initiated from the first tap). Interestingly, you can get the second tap, and thus the window to maximize, if the second tap happens just a little bit more slowly (but not too slowly).
Perhaps the fact that after the first tap the drivers send a move event/request (to the Xserver/compositor, respectively) is what confuses GNOME? In any case, when using the mouse both clicks are delivered.
Although I can't say for sure if this is erroneous behavior in GNOME or just some behavioral incompatibility, I think this is worthy of an upstream GNOME bug/discussion.
I have attached a file containing Wine log snippets (running with WineX11/Xwayland, GNOME 45.1) for the double-click, double-tap and double-tap with small delay scenarios.