| Summary: | Useraction menu closes when focus passes to another window | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Alexander Ewering <alex> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | investigated, reproducible |
| Priority: | NOR | ||
| Version: | 4.8.0 | ||
| Target Milestone: | 4.9 | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.9 | |
|
Description
Alexander Ewering
2004-05-17 15:39:45 UTC
I just found out this problem only occurs if there is a window behind the context menu, and focus is passed to the other window. Please provide more details, like focus policy used. Focus policy is "focus follows mouse", Auto-raise is OFF. In my opinion, another window getting focus behind a context menu should not destroy the context menu. I can confirm said behavior; but I don't think that the alternative is a good idea. I've seen another environment keep the context menu up while I change focus; its not wanted in most cases. (The context menu should only be visible while the actual context has focus, right?) I suggest to close this as a 'will not fix'. As a slight 'tweak' the context menus should be positioned mostly within the parent window. So when I right click on a titlebar the context menu could appear at least (say) 10 pixels from the edge of the window. I agree with comment #4. After a second thought ... There is actually a QStyle option (along with a hidden KStyle setting) that makes this possible [it makes the area where one can move the mouse to a submenu w/o closing it bigger], but the Qt implementation had some major flicker problems, so it's not on by default Apparently, this _seems_ to be an issue with the "title bar context menu", but is _not_ an issue with an "application context menu" or "desktop context menu". I.e. right-clicking on the konsole window produces a context menu that doesn't tend to disappear if you move focus to another window, while right-clicking on the konsole's title bar brings up a context menu that tends to disappear, as described here. This is all with "focus follows mouse". Please compare this behaviour with the one reported in bug 142040. I'm using only the touch pad as a pointing device with the focus follows mouse policy. This is an incredibly annoying behavior that shows up whenever I wish to move a window to another desktop. I usually have a maximized window per virtual desktop and small windows like konsole or messenger windows that I wish to move somewhere else trigger this behavior. Furthermore, this is inconsistent with the fact that the application menus (such as the file menu) do not go away if I move the pointer to another application. In fact the focus is retained on that window. I do not agree with comment #4, why should the menu bar context menu behavior be any different than the application menu? And the suggested tweak of moving the menu somewhere more inside the parent window (therefore away from the pointer) seems unproductive. Plus, sub-menus (such as the Advanced or To Desktop) might still be outside the parent window. Steps to reproduce: 1. set focus policy to Focus Follows Mouse 2. open user actions context menu (alt+f3 menu) 3. move mouse to another window Actual Result: User action menu closes and focus is passed to other window Expected Result: User action menu does not close. The problem is that the context menu is bound to the active window. When a focus change occurs the menu is closed. Consequently the menu closes when the mouse moves to another window with focus follows mouse. I only see one solution: ignore the focus change request with focus follows mouse if a useraction context menu is open. This is also not realy correct. In summary I think it is not possible to get a real solution to this problem. I change to bug as I consider this more to be a bug than a feature request. (In reply to comment #10) > I only see one solution: ignore the focus change request with focus follows > mouse if a useraction context menu is open. This is also not realy correct. Yes, is. "Normal" QMenus grab the pointer and relase it on a (even external) click or when the focus gets passed to another window. However the only reason why this one reacts to crossing related focus change is that kwin pre-handles the event (against the grab) because it's the very same event handler (blahblahblah) long story short: stopping short on the EnterEvent handling if the menu is up will make it act like any regular popup (as of QMenu) Git commit 0a69665f8e3d1d9698e3c7b72a41980f3f9cf97e by Thomas Lübking. Committed on 16/04/2012 at 18:16. Pushed by luebking into branch 'master'. export clientpopup mapping state and use it to skip mouse driven focus changes FIXED-IN: 4.9 REVIEW: 104620 M +1 -1 kwin/events.cpp M +6 -0 kwin/workspace.h http://commits.kde.org/kde-workspace/0a69665f8e3d1d9698e3c7b72a41980f3f9cf97e |