Re: [Pan-users] Firefox starts *behind* Pan window

[Duncan]

Maurice posted on Fri, 05 Jul 2013 11:27:55 +0000 as excerpted:

> On Fri, 05 Jul 2013 01:51:05 +0000, Duncan wrote:
> 
>> Unless I'm missing something, that would be a window-manager setting,
>> not a pan or firefox setting.  Probably something to do with
>> focus-stealing- prevention.
>> 
>> What window-manager are you using?
> 
>  KWin. And in System Setings/Window Behaviour the 'focus-stealing
> prevention level is set at 'none'.
> 
> Perhaps it's a KDE v. Gnome thing, as with KDE app's (e.g. Kmail,
> Kwrite) Firefox does come up on top (i.e. steals focus), but it did not
> happen with 'old' Pan.

FWIW, with focus-stealing-prevention set to medium, here... I just 
checked here and firefox (sometimes, see below) comes up behind pan when 
I click a link in pan, too.  However, it has never been a big issue here, 
because I use kwin's window rules to force pan to a just-slightly-shorter-
than-maximized size and position on my lower monitor, while firefox is 
normally vertically maximized and horizontally half-screen, so the 
firefox titlebar remains visible/clickable.

Alternatively, since I have kwin set to "smart-position" new windows on 
the "active" desktop (the one the mouse is on), I can click the pan link 
and quickly point to the middle monitor instead of the lower (primary 
working) monitor, to have firefox open on the middle (secondary working) 
monitor instead.

Here's the same screenshot I posted the other day as an illustration, tho 
in it it's claws-mail in feed-reader mode on the bottom monitor, with pan 
in the middle, but they're both in the "just-shorter-than-maximized" 
state I described, with a half-monitor firefox window visible below the 
claws-feeds window, the firefox titlebar accessible just above the feeds 
window (which is set to no titlebar).  (Again, moderate NSFW warning due 
to swimsuit model firefox skin.)

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png


**BUT**, the coming-up-behind behavior didn't match what I remembered 
from claws-mail in feeds mode, where I tend to click a LOT of links and 
often end up with a dozen or more firefox windows open (firefox is set to 
open a new window when I click a link in some other app).  I (usually) 
have to click the (almost maximized) claws window to bring it back to the 
top, after clicking a link in claws, since firefox then (normally) opens 
above claws.

And claws and pan are both gtk apps (gtk2 here, as I don't have gtk3 
installed).

So I began to think about it, and here's what seems to happen here.

Consider: firefox has always been considered a somewhat large app, taking 
a bit to initialize, particularly for people running quite a few 
extensions.  I've never had too much of a problem with it, partly because 
I run a reasonably fast machine, and partly because I've simply gotten 
used to it, but I know that firefox is infamous in some circles due to 
that launch delay, which apparently drives some (either more sensitive to 
it or with slower systems) crazy.

So, what I found out after a bit of experimenting, is that when a firefox 
window is ALREADY running (perhaps minimized, or on another desktop), so 
the click (in either claws or pan) to open a new firefox window doesn't 
have to start a new firefox, just a new window of an existing firefox, 
firefox opens that new window fast enough that it appears ON TOP of what 
I was doing.

But if firefox is NOT already running, so opening the new firefox window 
has to launch firefox as well, not just open a new window of an existing 
firefox, THEN the firefox launch process apparently takes just enough 
additional time that kwin doesn't associate it with the click that opened 
the window, and considers it a random window popping up instead, in which 
case it opens UNDER/BEHIND pan or claws-mail/feeds.

So the distinction appears to be whether firefox is already running in 
another window or not, and thus whether it has to do all the extra work 
of initializing (opens behind), or whether it's simply opening a new 
window in an existing instance (opens in front).

Try it there and see.  If you don't have the screen-space to comfortably 
do it on the same desktop, open firefox on a different desktop, then 
switch to the one you're running pan on, and click a link.  If I don't 
miss my guess, firefox will then open on top, since it doesn't have to do 
full initialization since it's already running, and thus will open fast 
enough that kwin associates it with opening in response to the click and 
acts accordingly, putting it on top.

But without firefox already running, it'll open too slowly, and that 
association is lost, so kwin opens it behind.

At least that's the behavior I see here, with medium focus-stealing 
prevention, on a reasonably fast machine.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman