[Bug 59345] New: Popup menus in audio plugins break for the whole session
http://bugs.winehq.org/show_bug.cgi?id=59345 Bug ID: 59345 Summary: Popup menus in audio plugins break for the whole session Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@list.winehq.org Reporter: 96gz52jbf@mozmail.com CC: rbernon@codeweavers.com Regression SHA1: f24d38e1efe96598918b59ceb268fbfbf17f558d Distribution: --- In many audio plugins popup and dropdown menus work initially but by opening them multiple times they begin to open less and less frequently until clicking on the buttons to open the menus does nothing. The effect then persists across plugins and even newly launched plugins until the window manager is restarted (logging out and logging back in also works). As I was debugging this I did notice that using WINEDEBUG=+relay slowed things down enough for the menus to open again. With yabridge the breakage is reached pretty quickly if the project uses many Windows plugins through Wine. I've been able to consistently reproduce this with the standalone versions Toontrack's plugins (EZBass, EZDrummer 3), which use JUCE although I don't know if that's relevant, by simply clicking on the menus repeatedly. Relatively quickly the clicks seemingly stop working as the menus stop opening. I did regression testing and found out that in the already broken session using Wine 10.4 makes menus open again. The exact commit that results in the menus not working in an already broken session is 30fa691d99df7d6dfe37d16fe708d603919f9fd1. However, reverting it for the Wine 11.1 has no effect and everything remains broken. So I did more regression testing and found out that with Wine 10.16 and a fresh session the breakage never happens. The commit that results in the breakage is f24d38e1efe96598918b59ceb268fbfbf17f558d, which reverted for Wine 10.17 fixes things but not for Wine 11.1. Commit 0a7082d37efba17f5badea361c8727f424192e68 added a condition to f24d38e1efe9 that resulted in a merge conflict so I reverted that as well. With the commits from the previous paragraph reverted, the issue persisted and with more regression testing I discovered that commit c6cab075f512f95b0f350d0d8c51fff3e3c44a9f (related to https://bugs.winehq.org/show_bug.cgi?id=59102) also needed to be reverted. After that the menus open normally and the session-wide breakage doesn't happen. In summary, commits f24d38e1efe96598918b59ceb268fbfbf17f558d and c6cab075f512f95b0f350d0d8c51fff3e3c44a9f result in a session-wide state where the popup menus stop opening entirely in multiple audio plugins. Initially they open normally but by constantly clicking on the menu buttons, they first start to open less reliably until them not opening becomes permanent. Restarting the window manager fixes it. This happens in a KWin Wayland session but not in an X11 session nor did it happen using IceWM. That does mean it could be an issue with XWayland and not Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 96gz52jbf@mozmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 gogokily@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gogokily@gmail.com --- Comment #1 from gogokily@gmail.com --- Many plugin popups are broken. Its 50% chance they will open on first click (when plugin is first opened) but on consecutive click they wont open at all -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #2 from Rémi Bernon <rbernon@codeweavers.com> --- Hi, thanks for the bug report. Could you detail how to reproduce this easily if there's an easy way? I've been able to use Carla with some free plugins in the past to work with yabridge, would that be enough? Otherwise maybe if you can attach a log file with WINEDEBUG=+timestamp,+pid,+loaddll,+seh,+win,+message,+msg,+x11drv,+event when things are broken / working, something would stand out. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #3 from 96gz52jbf@mozmail.com --- Created attachment 80339 --> http://bugs.winehq.org/attachment.cgi?id=80339 Screenshot of Surge XT showing buttons to click It seems to happen with any Windows plugin made with the JUCE framework. I managed to reproduce it with the Windows version of Surge XT just now though it took a bit longer than with the Toontrack plugins. You don't need to use yabridge to reproduce it and the standalone version of Surge XT will do. https://surge-synthesizer.github.io/downloads/ To reproduce the issue you need to just keep on clicking the highlighted buttons until the popups start to open less reliably. With Surge XT it seemed to take a few minutes before it happened and I'm not certain if closing and reopening the program speeds it up. Once they've started to not open with every click the effect will persist throughout the session in other plugins. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #4 from 96gz52jbf@mozmail.com --- Created attachment 80340 --> http://bugs.winehq.org/attachment.cgi?id=80340 Log of clicking on buttons in broken state This is taken when the popups fail to open most of the time. Once the WINEDEBUG flags are set, they do open most of the time. So slowing things down with the logging makes it work more reliably. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #5 from 96gz52jbf@mozmail.com --- Created attachment 80341 --> http://bugs.winehq.org/attachment.cgi?id=80341 Log output in broken state with the commits reverted This is the WINEDEBUG output in a broken state, but using Wine with the bisected commits reverted. Everything works as expected with this version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #6 from 96gz52jbf@mozmail.com --- Created attachment 80342 --> http://bugs.winehq.org/attachment.cgi?id=80342 Log output with Wine 11.2 in a working state This is the WINEDEBUG output just after logging in (i.e., after restarting the window manager) when the popups still work normally. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #7 from Rémi Bernon <rbernon@codeweavers.com> --- Created attachment 80365 --> http://bugs.winehq.org/attachment.cgi?id=80365 Test showing broken behavior Although the behavior may seem regressive, there's been various issues with message processing around the blamed commits, and it seems to be timing dependent. The issue comes from window focus not matching Windows, and what the application expects. The application creates five windows each time it opens a menu. Four of the windows are transparent layered windows (WS_EX_TRANSPARENT | WS_EX_LAYERED), which are used for some unknown app-specific purpose. The fifth window is a classic WS_EX_TOOLWINDOW / WS_POPUP window. They are all created / shown / stacked in a specific order by the application. The windows are shown with SW_SHOWNA which is supposed to show the windows on screen but not activate them. We implement this through the EWMH X11 protocol, by setting _NET_WM_USER_TIME = 0 property before mapping the window (https://specifications.freedesktop.org/wm/latest/ar01s05.html#id-1.6.16). This is meant to tell the window manager not to activate it upon mapping, neither through XSetInputFocus, nor WM_TAKE_FOCUS. Yet, we still seem to sometimes receive WM_TAKE_FOCUS events, which we need to respond to by activating the window, as it may come from a user action without any way for us to tell. The application then gets confused as it receives focus change messages when it does not expect so. This then varies a bit depending on which window gets activated and it seems like it only decides to close the menu if the non-layered window is, possibly assuming that the window got activated by a mouse click on a menu item.
This happens in a KWin Wayland session but not in an X11 session nor did it happen using IceWM. That does mean it could be an issue with XWayland and not Wine.
This seems to be the reason for the WM_TAKE_FOCUS we receive, and it looks like that it also depends on where the window is being opened. I can reproduce this on XWayland with GNOME, with the attached test, which passes on windows or with a X11 session. It looks like that if a window is created above, or moved above right after mapping, the currently active window, it gets the WM_TAKE_FOCUS every time, regardless of _NET_WM_USER_TIME value. If the window is mapped elsewhere, it doesn't. This is IMO a broken EWMH implementation, either from XWayland or from the X11 window manager under XWayland, and it should be fixed there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59345 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|f24d38e1efe96598918b59ceb26 | |8fbfbf17f558d | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla