When you click on the clipboard clear button, a dialog box appears with confirmation or cancellation of the action. But if you open this dialog box while another application is loading, the clipboard cleanup dialog box will be behind the open application. At the same time, the plasma panel becomes completely inactive until the user confirms or cancels this dialog box. This is confusing, because the user has to guess that it's not the plasma panel that is frozen, but rather that they need to minimize the application window that opens and confirm/cancel the clipboard dialog box. It is worth making the clipboard dialog box on top of the other windows so that it is not lost, or making the plasma panel active for interaction. STEPS TO REPRODUCE 1. Open for loading any heavy application that takes a long time to run. 2. Open the clipboard cleanup dialog. 3. The clipboard cleanup dialog will be behind the opened application and will make the plasma panel inactive. Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.12-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland
Created attachment 186013 [details] The clipboard dialog box is lost behind another application that opens, and the plasma panel becomes inactive. Video demonstration of an inactive plasma panel with an open clipboard dialog box
Hi, thanks for the report and your video. I agree it can be confusing if a blocking dialog is open and the user can't find it anymore or doesn't understand why it's blocked now. What could be improved I think could be improved imo: if that Yes/No dialog is open and the user clicks the widget that the dialog should then re-activate and get focus. I don't think these kind of dialogs should be forced into the foreground as long as they are open, that would be a usability nightmare and Plasma doesn't do it this way thankfully. There was a similar issue with file chooser dialog in Chrome where the dialog blocked the browser but could get pushed into background so the browser window became completely blocked. They solved it by pushing the dialog into foreground first when the browser was activated. fyi I'm putting it to confirmed since it's reproducible but it may still be dismissed by the KDE people.
*** This bug has been marked as a duplicate of bug 478050 ***