| Summary: | active popup breaks click-to-focus | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Leon Bottou <leon> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
I can confirm this bug on KDE 3.5.4 from Kubuntu Dapper. |
Version: (using KDE KDE 3.5.2) Installed from: Ubuntu Packages Compiler: gcc-4.01 OS: Linux This bug happens in both 'click-to-focus' and 'focus-follows-mouse' modes. It might be related to a lot of 'focus-follows-mouse' bugs because it is more annoying in this mode. Steps to reproduce: ------------------- 1) Make a desktop with two partially overlapping konqueror windows. Make sure that one can see the 'new tab' button of the lower window. 2) Perform a quick single click on a menu of the upper konqueror window, so that the menu popup is displayed and stays there without maintaining the mouse button depressed. 3) Move the mouse over the 'new tab' button of the lower window and perform a quick single click. The popup disappears and the 'new tab' button is triggered. But the lower konqueror window remains inactive. Analysis. --------- When a popup is displayed, a mouse click outside the popup window hides the popup and is passed to the inactive window below the cursor. But that does not cause the activation of the underlying window because the window manager is not informed of that click. I guess the active mouse grab on the popup window trumps the passive mouse grab placed by kwin on the inactive windows. I still don't get how the click is still passed to the inactive window. That must be done by the popup code I guess.... In 'focus-follows-mouse' mode, this becomes very annoying when it happens in conjunction with a popup associated with a system tray icon or a panel applet. In my typical setup, I have a konsole and an emacs window. Suppose I am working in the console. In order to access the klipper menu, I need to move the mouse over the emacs window. The emacs windows gets activated. I popup the klipper menu. Changing my mind, I return the cursor over the (now inactive) konsole window. I click to pop the klipper menu down and start typing. Alas, the focus revers to the emacs window, and my keystrokes end up modifying my program. I am getting really mad over this. Hence the long bug report. I can see two ways to fix it. When hiding a popup because of a mouse click: - "revert-focus-to-click-target": * if the click happens inside the popup, perform the popup action and re-activate the popup owner. If the popup owner does not accept focus, do not activate any other window. * if the click happens outside the popup, activate the window below the cursor and pass the click. If there is no window below the cursor, do not activate any other window. - "revert-focus-to-popup-owner": * regardless of the mouse position, activate the popup owner. If the popup owner does not accept focus, do not activate any other window. The latter option is surely easier to implement. It forces me to perform another click to reactivate my konsole, but it prevents the lossage that comes with activating the wrong window. - L.