User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy) Build Identifier: Thunar fails to focus newly created windows with 'Focus stealing prevention' on. Thunar just flashes in the taskbar until you manually give it focus... Reproducible: Always Steps to Reproduce: 1.Start Thunar 2.Watch it flash in the taskbar 3. All installed Xfce components are the latest SVN versions...
Olivier, any ideas?
Yeah, it's been fixed already a few days ago. Please update to SVN trunk.
It still doesn't work here... I have these revisions installed: harold@DBWS439:~$ emurge -p xfwm4 thunar emurge/purtage - a crippled gentoo/emerge/portage clone for ubuntu... These are the packages that would be merged, in order: [ R ] xfwm4-9999-r24143 [9999-r24143] [ R ] thunar-9999-r24083 [9999-r24083]
Actually, what has been fixed was an issue with Terminal. Focus prevention takes its source from either: - startup notification timestamp - NET_WM_USER_TIME timestamp if that given timestamp is older than the latest user timestamp update, it means than a user interaction occurred in between and the new application should not be focused (which is what happen here). You may have to update the NET_WM_USER_TIME with a more accurate timestamp. The same behavior occurs in both metacity and kwin too, so it's not xfwm4 specific.
I just turned on 'Focus stealing prevention', but cannot reproduce your problem.
Steps to reproduce: 1. I have Thunar mapped under Winkey-E 2. On a fresh login, press Win-E and Thunar will open focussed 3. Close the Thunar window 4. Press Win-E again and Thunar will open unfocussed... So it only happes if Thunar has been launched already(?)
Opening a folder from your desktop also launches Thunar in an unfocussed state...
Dunno why I got assigned with this bug, the problem is not in xfwm4, reassigning.
> So it only happes if Thunar has been launched already(?) Yes, makes sense, it seems Thunar does not update its NET_WM_USER_TIME when driven by DBUS.
Benny, I've enabled some traces in xfwm4 that show that the new Thunar window don't update their NET_WM_USER_TIME : Current 2884303878, new 2884302516 Current 2884321371, new 2884302516 Current 2884328218, new 2884302516 Current 2884330313, new 2884302516 Current 2884331401, new 2884302516 ("Current" is the currently focused window, xfdesktop in that case, "new" is the newlay mapped window, Thunar in this case). The problem also shows because the launcher (xfdesktop or Thunar? I'm not sure...) either don't use startup notification or do not set startup time field in startup notification (I made a patch for the panel a while back to add the startup time, during the xfce 4.2 release cycle IIRC). I hope this helps ;)
I've also created a similar bugreport for mousepad. Maybe you can 'trace' that one too? http://bugzilla.xfce.org/show_bug.cgi?id=2677
The fix would be to use the click time (X event time) and pass it as startup notification timestamp for startup time.
There's some similar problem with eye of gnome launched from Thunar. No problem if the program was launched from Terminal. Evince (or xv) launched from Thunar don't have the problem.
(In reply to comment #12) > The fix would be to use the click time (X event time) and pass it as startup > notification timestamp for startup time. > Benedikt, Can you please check if the proposed fix by Olivier makes sense?
For the record, Terminal has the same issue. Seems that it doesn't update its startup timestamp if startup notification is not enabled. Here follow several launches of Terminal using the panel, w/out SN. Current 750066286, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 Current 750070834, new 750060377 It seems the problem doesn't occur if S/N is enabled in the panel launcher. Or at least, it's harder to trigger. Also, maybe,the use of exo-open or even xfterm4 may break the S/N process (like passing the S/N id? Dunno, just trying to guess....) Hope this helps.
add myself to cc list (ristretto uses thunar dbus interface to get the file properties dialog... and thus suffers from this bug)
We added timestamp parssing to dbus last year, so this should work now.