GNOME Bugzilla – Bug 164675
Buggy apps trying to raise (and focus?) themselves without user interaction
Last modified: 2005-01-24 20:24:32 UTC
Please describe the problem: When an application steals focus, the application is bought to the front and focused but none of the other focus indicators are updated. Alt-tabbing still behaves as if the previous (now unfocused) application is focused, and the gnome-panel still shows the previous application as focused. Steps to reproduce: 1. Allow application to steal focus (eg refresh a gmail browser window and switch away from it) 2. 3. Actual results: No focus indicators are updated Expected results: Focus indicators updated. Does this happen every time? Yes Other information:
Works for me. What version of Metacity? Any chance you could take a screenshot to show what you're seeing (use 'gnome-screenshot --delay=10' in a terminal to get a screenshot to be taken 10 seconds after hitting enter)?
Created attachment 36296 [details] Screenshot of firefox raised to top Not really a bug in GNOME at all, can probably close this really.
I realised that Firefox isn't actually getting the focus at all, it's just being raised to the top of the window stack. So not really a bug at all, just confusion on my part.
Well, that perhaps looks like a different bug. Why can firefox's stacking be reshuffled so that it's on top, without Metacity deciding that it needs focus. I think I've seen this before, and the window is not being raised due to user interaction, which seems really annoying and buggy. I'm not sure how to duplicate, though. Do you have good steps that I can use to get that to happen so I can investigate?
I've created a web page here: http://benroe.com/files/focus.html that calls window.focus() five seconds after you click the link in it, which causes the behaviour shown in the screen shot.
Thanks for the test page. Apparently, neither mozilla nor firefox will take the focus (at least not with CVS HEAD Metacity--does it do so for you?), and only firefox will attempt to raise itself (which is partially why I thought this was sporadically; I switch off between the two often and forget which I'm using). Firefox apparently raises itself by sending an xconfigurerequest with the xconfigurerequest.detail set to Above. Without understanding all the cases where xconfigurerequest are used, my gut reaction is to just shut all the raise/lower ones off. And, in fact, I now have a patch to do that locally. ;-). As Havoc says in a comment in that area of the code, "...in fact all client attempts to deal with stacking order are essentially broken, since they have no idea what other clients are involved or how the stack looks." But maybe that's not possible (Motif app support or something similar), and we should instead lodge a bug against Firefox for this broken behavior. However, the thing that puzzles me is that this was supposed to be a _focus_ request (the javascript function is named window.focus()). Why does there appear to be no focus message, and only a request to raise? Havoc: any words of enlightenment here?
Metacity originally ignored the client configure requests; and I think for a while the "disable workarounds" config setting would put it in a mode that ignored them. However, this broke a few legitimate cases and I had to give up. That was years ago so of course I don't remember what the cases were. As to why javascript focus() raises but doesn't focus, I don't know the answer to that one.
Most likely moz/firefox should be calling gtk_window_present() in this case, btw. Maybe we should suggest that to them.
Can that be done by just simply cc'ing Chris? ;-) Since we have to punt and hope Firefox/Mozilla change their behavior to something that can be handled more correctly, should we just mark this as NOTABUG or WONTFIX?
So web pages can't actually grab your keyboard focus. That's a huge security problem. "And you thought popups were annoying."
Good point. So, mozilla/firefox decided to not grab focus because it's bad. Would it be possible to also not raise the window (or at least not with an xconfigurerequest), since that is also bad (just from a UI standpoint instead of from a security one)? Oh, and Havoc: I have to disagree with the use of gtk_window_present()--it would probably result in the window unconditionally being raised _and_ taking the focus away. That could be fixed if gtk_window_present() took a timestamp parameter to know the user interaction time that caused the focus request to happen (instead of just using gtk_get_current_event_time as it does now); but that would be an API/ABI break and thus isn't feasible. gdk_window_focus(), on the other hand, should would work (modulo a metacity bug that will raise on _NET_ACTIVE_WINDOW messages even in the cases when it doesn't focus), assuming that _NET_ACTIVE_WINDOW has the semantics we really want in this case...
There's a preference to turn off the raising of windows: mozilla.widget.raise-on-setfocus Set it to 'false' and it will stop raising windows.
Yeah, but nobody cares about the pref, what matters is the default ;-) Agreed that gtk_window_present() is wrong if the intent is to not focus the window. My view is that a click to focus desktop has an invariant "on top iff focused" so the raise should be off by default in firefox.
Yeah, I definitely agree with Havoc (why is there a preference to turn a bug off?), but that means that this bug is NOTGNOME.