Bug 523784
| Summary: | Window not focused with sloppy/mouse mode and strict new window mode | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Olivier Fourdan <ofourdan> | ||||
| Component: | metacity | Assignee: | Owen Taylor <otaylor> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | desktop-bugs <desktop-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.4 | CC: | kem | ||||
| Target Milestone: | rc | Keywords: | Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-11-10 19:03:28 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This doesn't quite make sense to me. My understanding of: meta_prefs_get_focus_new_windows () != META_FOCUS_NEW_WINDOWS_STRICT Is that it means: Don't focus new windows, even if a terminal previously had focus So it really has nothing to do with what happens when a window is denied focus and pops up under the mouse pointer. (focus_new_windows == STRICT is not at all the same as the old strict_pointer_mode patch we had.) The current behavior is pretty consistent - it's the same thing that happens as when you alt-tab away from the focused window - you have to click or enter-leave to get the focus back there. In the absence of strict_pointer_mode, the only other behavior I could think of would be to make it so that when the pointer window isn't the focus window any mouse motion (maybe with a few pixels of slop) resets the focus window. That would require polling the mouse position continually - though that isn't all that expensive when done 10 times a second. There are 3 patches scheduled for 5.5 that I think should make a patch in this area unnecessary. Bug 530261 - Handle windows under pointer without focus better With this improvement, if a window is mapped under the pointer but doesn't get the focus, or if a window steals focus from the window under the pointer, then the user can return focus to the window under the pointer with a small motion of the mouse. The idea here is to be "best of both worlds" - to avoid most of the inconvenience when the window under the mouse loses focus without the breakage of keyboard navivation produced by the old strict_pointer_mode patch Bug 530262 - Allow configuring windows that should not be focused Even with the above patch, its still slightly inconvenient when focus is stolen away. This focus stealing is typically from old legacy applications. A GConf key is added to allow specifying windows that should never steal focus - for example it could be set to: (and (equals class "Myemailprog") (equals name "New email from *")) to disable email notification windows with matching titles from stealing focus. Bug 530263 - Allow configuring new windows to be always placed on top One of the biggest annoyances with focus stealing prevention is if an application gets focus stealing prevented and is mapped underneath and the user doesn't notice it or has to go down to the taskbar to find unbury it. This adds a configuration option so new windows are always mapped on top, even when they don't get focused. I'd suggest, if possible, using 'smart' new window mode, not 'strict' new window mode. The config key in bug 530262 should be a better way of working around focus being stolen away from a terminal than the 'strict' new window mode. I'm going to mark this as a duplicate of bug 530261, since it's most similar to that. *** This bug has been marked as a duplicate of bug 530261 *** |
Created attachment 361322 [details] Proposed patch Description of problem: In strict mode, metacity will not focus nor place windows on top of the stack when run from a terminal. But with sloppy focus, if the newly mapped window falls under the mouse pointer, it's yes not focused while it should be, forcing the user to leave and re-enter the window with the pointer to focus it. Version-Release number of selected component (if applicable): metacity-2.16.0-12 How reproducible: 100% reproducible Steps to Reproduce: 1. Make sure the options are set as follow (e.g. use gconf-editor) /apps/metacity/general/focus_new_windows = strict /apps/metacity/general/focus_mode = sloppy 2. Run a terminal 3. Move the pointer outside of the terminal window, keeping the terminal focused (sloppy focus) 4. Launch different apps from the terminal Actual results: When a window is mapped under the mouse pointer, it's not focused. Expected results: Window should not be focused in strict mode + sloppy focus *unless* the pointer is already in the window. Additional info: Historically, newly mapped window would be placed on top of the stack and focused by metacity. Therefore, the EnterNotify events ought to be ignored when mapping new windows. This is the purpose of the sentinel window used in meta_window_show() in src/window.c: ----B<--------------------------------------------------------------------- /* Prevent EnterNotify events in sloppy/mouse focus from * erroneously focusing the window that had been denied * focus. FIXME: This introduces a race; I have a couple * ideas for a better way to accomplish the same thing, but * they're more involved so do it this way for now. */ meta_display_increment_focus_sentinel (window->display); ----B<--------------------------------------------------------------------- But the "strict" mode changed that as the windows would appear unfocused and not on top of the stack. This does not work with sloppy/mouse focus mode because the user would have then to leave and re-enter the window behind the cursor to focus it in sloppy/mouse mode. Therefore, in "strict" mode, where the window is not necessarily focused, the sentinel should not be used so that the EnterNotify event is not ignored and the window focused as expected when it falls under the mouse pointer. This is what the proposed patch does.