I am in konsole, type firefox and firefox is started but its window doesn't get the focus. That is a regression against kdelibs4.x based version of kwin.
focus stealing prevention, try setting to "none" for confirmation (please) @Martin, time to start breaking KWin/5? port https://git.reviewboard.kde.org/r/110919/ and friends for a start ;-)
Yes, none instead of low makes it work.
*** This bug has been marked as a duplicate of bug 337798 ***
not a duplicate of bug 337798.
Git commit 6c04f136a9826ebce80ebf8dc9407ab2b43eba3b by Martin Gräßlin. Committed on 21/11/2014 at 10:35. Pushed by graesslin into branch 'master'. Add KStartupInfo::createNewStartupIdForTimestamp KStartupInfo::createNewStartupId is supposed to return a new id with a properly setup user timestamp. But if QX11Info::appUserTime returns 0 this was included in the id and cannot be considered a properly setup user timestamp. An app user time of 0 is the case for klauncher. If an application uses this timestamp of 0 passed from the startup notification it causes problems with passing focus to it from KWin. The application sets the timestamp in the _NET_WM_USER_TIME property and the value "0" has the special meaning of requesting to not be initially mapped. KWin honors that and doesn't focus the window. An application is not supposed to interpret a 0 time stamp passed through the startup notification as a special value to get the current time. It is totally fine to expect that it gets a proper value passed. Thus one cannot blame applications for not interpreting this value accordingly. An example for an application passing the 0 to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5 session through e.g. the launcher results in KWin not passing focus to it and instead demands attention. This is clearly wrong and not intended. The solution in this change is to get the current timestamp from the X server in case the appUserTime is 0. For this a new method createNewStartupIdForTimestamp is added which takes timestamp as an argument. ::createNewStartupId is changed to use this method and fetches the current timestamp from the X Server. On other platforms the value 0 is used. The change implies that for all current code the timestamp will be fetched from X. Due to the changes in the underlying stack triggering the bug in the first place, this is an important improvement. Instead of relying on potential incorrect data KStartupInfo ensures that an up to date value is used. Application knowing the up-to-date state can be adjusted to pass in the proper value. This change fixes the described problem with Firefox: it now gets properly focused on starting through a launcher. REVIEW: 121197 FIXED-IN: 5.5 M +21 -0 autotests/kstartupinfo_unittest.cpp M +12 -6 src/kstartupinfo.cpp M +15 -0 src/kstartupinfo.h http://commits.kde.org/kwindowsystem/6c04f136a9826ebce80ebf8dc9407ab2b43eba3b
(In reply to Martin Gräßlin from comment #4) > not a duplicate of bug 337798. Sure? > > I am in konsole, type firefox and firefox is started but its window doesn't get the focus.
Well Albert confirmed in the Review Request that the patch fixes the bug. So I assumed it's not the same issue.
It fixed my bug as far as i could remember, didn't try any of the other stuff my bug was duplicated against. I can give it another try later if you tell me exactly what you want me to test.
There's (probably) a difference is starting firefox from konsole or via a launcher. Calling the binary directly (assuming it's not a script that somehow launches a service via krun) does not invoke kstartupinfo (eg. you also won't get a bouncing cursor etc.), so should not be affected by this patch. What you need to try w/ the patched version is to run "firefox" in konsole, and that does not activate firefox here. Not even "sleep 5; firefox" will.
Sorry i'm a lame tester, it's not yet fixed from the konsole, only from the menu.
commit 27a48496a15ddd421ecf664661d57c2946d733df Author: Thomas Lübking Date: Thu Nov 27 23:24:05 2014 +0100 explicitly update xTime for the kde_net_wm_user_creation_time diff --git a/events.cpp b/events.cpp index b00abe2..ed012d7 100644 --- a/events.cpp +++ b/events.cpp @@ -387,6 +387,7 @@ bool Workspace::workspaceEvent(xcb_generic_event_t *e) !QWidget::find(event->window) && !event->override_redirect) { // see comments for allowClientActivation() + updateXTime(); const xcb_timestamp_t t = xTime(); xcb_change_property(connection(), XCB_PROP_MODE_REPLACE, event->window, atoms->kde_net_wm_user_creation_time, XCB_ATOM_CARDINAL, 32, 1, &t); } You may give this a try (not tested w/o alternate FSP approach, but actually should do given the findings in the other bug) *** This bug has been marked as a duplicate of bug 337798 ***
It does half fix it. If i don't have firefox running and i start it from the shell, it now gets focused. But if i have firefox running and i write "firefox" again in the shell, it won't get focused, while if i start it from the K-Menu it will.
> It does half fix it. If i don't have firefox running and i start it from the > shell, it now gets focused. > > But if i have firefox running and i write "firefox" again in the shell, it > won't get focused, while if i start it from the K-Menu it will. interesting: do you know how it behaved back in 4.x?
I doubt it will work - the second window has the very same _NET_WM_USER_TIME as the existing one (now older than the user time of konsole) and because it's not the first in its group, _KDE_NET_WM_USER_CREATION_TIME (recent enough) won't be taken into consideration. The window only gets active when another one in its group (the 1st FF window) has the focus or no window has at all. $ kstart --service /usr/share/applications/firefox.desktop # fail, user time is 0 $ kstart --activate --service /usr/share/applications/firefox.desktop # fail... $ kstart --activate firefox # success =)
(In reply to Martin Gräßlin from comment #13) > > It does half fix it. If i don't have firefox running and i start it from the > > shell, it now gets focused. > > > > But if i have firefox running and i write "firefox" again in the shell, it > > won't get focused, while if i start it from the K-Menu it will. > > interesting: do you know how it behaved back in 4.x? Just tested and behaves the same.
@Martin, I cannot create a review RB demands --full-index and then fails by Line undefined: error: unable to find b00abe214fb1a183d6a6313e52e67c5d6aa65071 fatal: git cat-file b00abe214fb1a183d6a6313e52e67c5d6aa65071: bad file The patch is on top of commit 060b3100826f7eab9ba988af31c433e66755ea4e Author: Martin Gräßlin Date: Fri Dec 12 22:12:11 2014 +0100 [aurorae] Do not update shadow from ::paint
Albert, gitven the findings in comment #14, this WONTFIX from the kwin side. Firefox needs to update the usertime for the new window (instead of re-using the old), I assume the FF new window function relies on the old window usertime since new windows are usually triggered from there (w/ an implicit update to the usertime) What you can do is a) a "ff" script that calls "kstart --activate firefox" b) a kwin rule for firefox, forcing the focus stealing prevention to "none" (though be aware that mozilla has a record of being a veeeeery important client, calling for focus whenever it feels like ;-)
Well it's already marked as duplicate of other bug, if you prefer to mark it as invalid, sure, what is best for you guys.
The original bug is not affected, just the particular case where you call a second firefox window.
(In reply to Thomas Lübking from comment #16) > @Martin, I cannot create a review That's the patch from comment #11? ShipIt
Git commit f3a1d1bd3df0d17c2c37c57029901ea7077a6e7a by Thomas Lübking. Committed on 27/11/2014 at 22:24. Pushed by luebking into branch 'master'. updateXTime for kde_net_wm_user_creation_time explicitly Related: bug 337798 M +1 -0 events.cpp http://commits.kde.org/kwin/f3a1d1bd3df0d17c2c37c57029901ea7077a6e7a