------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=125676         
           Summary: popups trump focus activation
           Product: kwin
           Version: unspecified
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: kwin kde org
        ReportedBy: leon bottou org


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.