Created attachment 113078 [details] QMenu cleared by a timer with compositing enabled When an open QMenu is cleared through a function triggered by a signal (e.g. QTimer or a queued connection) it becomes invisible but its actions are working. The bug can be replicated using the following Qt app: MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); QToolButton *button = new QToolButton(ui->mainToolBar); QMenu* menu = new QMenu(button); button->setText("Menu"); button->setMenu(menu); button->setPopupMode(QToolButton::InstantPopup); QTimer* timer = new QTimer(this); connect(timer, &QTimer::timeout, this, [=](){ menu->clear(); menu->addAction("Menu 1"); menu->addAction("Menu 2"); menu->addAction("Menu 3"); }); timer->start(1000); ui->mainToolBar->addWidget(button); } - The menu should be cleared and populated every second but it appears and disappears. (See attachment) - When compositing is disable it works as expected and does not disappear. (See attachment) - Although the menu is invisible it still works. (See attachment)
Created attachment 113079 [details] QMenu cleared by a timer with compositing disabled
Created attachment 113080 [details] e.g. of QMenu working but invisible in Gwenview
Sorry, but KWin has nothing to do with that. It is not responsible for input handling. If the application reacts on input for a not visible window that is an application bug.
Thanks for your response, Martin. > KWin has nothing to do with that. It is not responsible for input handling. Could you tell us why you think input handling is the problem (we are mainly interested in the menu showing, because that's not working right, input handling seems fine)? > If the application reacts on input for a not visible window that is an > application bug. That's not the problem. The problem is that the menu is _invisible_ with compositing on, while with compositing off it is perfectly visible as it should be. Any suggestions in solving this on the application side? I guess a different code path in the application when compositing is off is not the way to go, but what else are we doing wrong? Perhaps it's a bug in Qt, but then why is it working fine with KWin's compositing turned off (on X11)?
Henrik can you upload the sample code that you've written.
Sorry David, I haven't written any additional sample code, I thought the code above was enough to show the nature of the problem. Is there any issue with Farid's code (besides omitting the boilerplate and not coming in tar.gz form)? If you are interested, this bug originates from the discussion in https://phabricator.kde.org/D13312 (please don't mind the detours over there).
Created attachment 113094 [details] Qt application reproducing the bug using a QTimer I have attached the entire Qt Creator project of the test application reproducing the bug.
Sorry I misunderstood from the description. Nevertheless I very much doubt that this is an issue in KWin. Relevant code areas haven't been touched in years. In such situations the fault is normally with the application or toolkit.
Before the bug was reported, I checked with a KDE 4 based system, where the share button is working fine. The only change on Gwenview's side since then is [1], where David ported from KMenu to QMenu. However, in KMenu [2] I could not find anything special really. Farid: I guess the last thing you could try is reporting this to https://bugreports.qt.io, and hope that it's a problem in Qt that is triggered by turning on KWin's compositing. [1] https://phabricator.kde.org/R260:2e69abc63776f05668a188f5ea3f58d0c8243754#change-OOnyLJlEzc3C [2] https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kmenu_8cpp_source.html