When you send a URL to a running instance of the Firefox web browser,
Firefox brings its window to the front, so that it is the top-most window.
Some people like that behaviour. Some do not. Well, I don’t.
With Firefox 2, putting this in my .fvwm2rc helped:
Style "Firefox*" IgnoreRestack
With the brand-new Firefox 3.0, the browser somehow manages to put itself
to the front again. I’ve tried additional options like “GNOMEIgnoreHints” and
“EWMHIgnoreStackingOrderHints”, but my FVWM 2.5.26 (on Fedora 8)
alway loses the battle.
Even worse, FVWM gets quite confused by that behaviour of Firefox.
If another window has the focus while Firefox puts itself on top of all
others, the commands “Raise” and “Lower” work reversed. I have to
focus a different window (any will do) to make FVWM aware of the
new stacking order.
It’s pretty strange how Firefox 3.0 is able to do that. It’s like it “bypasses”
the window manager with a magic trick. Is that possible?
No – nothing to do with FVWM at all. This is purely yet another FF fuck up, and reports of this kind deserve to be brought yet again to their attention.
I’ll do, I promise. This issue is one more of those little annoyances in Firefox 3.0,
and the list is growing from hour to hour. sigh
I’ve to admit that I’m not an expert for the X window system.
Just for me personally to understand this “dominant” behaviour of Firefox:
How can an application override the window manager in such a way?
Does it talk directly to the X server then instead of sending a nice
hint to the window manager (is this the way it normally works?) which
says “Hello, I’m the Firefox application, please bring my window to the
front and on top of all other windows”? Or is there a way that an
application can force the window manager to do things it normally
wouldn’t do?
Well, in this occasion it probably has something to do with the fact that the window is freely available to declare itself on top of others, overriding any internal stacking order the WM might have for windows (this is permissible by the ICCCM2 as well – if annoying). As far as your focus problem goes, that’s almost certainly a problem with xcrossing events. But FVWM is doing the right thing in this regard anyway. (The emphasis being that it will discard various {leave,enter}notify events so as not to refocus the previous window when the pointer moves either into the root window (if mousefocus implied) or another window.
