what if you launch it "sleep 5; foobar.sh"? (and stop typing in konsole afterwards)

no change

if you run "kwin --replace &" from konsole and then invoke a process the troublesome way, I assume the output is sth. like:

Activation, compared: 'ID: 52428804 ;WMCLASS: "foo" : "foobar" ;Caption: "Foo is Bar" ' : 336938840 : 337187682 : false 

(notice the trailing "false")?

yep:

User timestamp, ASN: 4294967295
User timestamp, final: 'ID: 27262998 ;WMCLASS: "a.py" : "a.py" ;Caption: "a.py" ' : 25250416
Activation, compared: 'ID: 27262998 ;WMCLASS: "a.py" : "a.py" ;Caption: "a.py" ' : 25250416 : 25254642 : false

KWin thinks the activity in konsole is more recent than the startup time hinted by xterm. Probably due to loose time updates with Qt5, thus remoterly related to https://git.reviewboard.kde.org/r/118447/

This should however "implicitly" fix with https://git.reviewboard.kde.org/r/110919/ which I intend to port for 5.1 (but not the 5.0 series)

*** Bug 338486 has been marked as a duplicate of this bug. ***

This is still a problem in 5.1.0.1, but it's inconsistent.

Test case:
1. Start with a new user account
2. Log in to a plain xterm session
3. Run startkde
 -> KDE starts up, and the xterm still has focus
4. Start a second xterm from the KDE menu
 -> The second xterm gets focus
5. Start Firefox from the KDE menu
 -> Firefox gets stacked between the two xterms
 -> The second xterm still has focus
6. Open the KDE menu and then close it again
 -> Firefox now has focus (blue outline) but is still visually below the second xterm

Arch Linux package versions:
firefox 33.0.1-1
kwin 5.1.0.1-2
plasma-desktop 5.1.0.1-2
plasma-framework 5.3.1-1
xf86-video-intel 2.99.916-3
xterm 312-1

*** Bug 340994 has been marked as a duplicate of this bug. ***

@Harald: could you please try whether the linked review request fixes the issue?

> when starting plain qapp+qwidget apps from konsole(4) the new window never gets focus. 
Doesn't work (but w/ FSP:none)

I doubt this is is any kstartupinfo related (notably since starting a non-kde application from konsole will hardly invoke it ;-)

This is a timing (and xcb event ordering) issue.

The creation time is not hinted via ASN, KWin resorts to the kde_net_wm_user_creation_time hack and that time is behind the user time of the active client - even if the time is fetched from the server on the creation event.

What happens after pressing enter in konsole is that:
a) konsole updates NET::WM2UserTime
b) the new client is created w/ a server time ahead of the one hinted by (a)
c) KWin handles the keypress event for konsole, with an event time ahead of (b) and updates the user time accordingly.
d) the window is mapped (and fsp checks times for possible activation)

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

> when starting plain qapp+qwidget apps from konsole(4)

Not fixed, just tried. Also see comment #10 on reasons.

so the duplicate from comment #8 is wrong

*** Bug 340994 has been marked as a duplicate of this bug. ***

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 340994

M  +1    -0    events.cpp

http://commits.kde.org/kwin/f3a1d1bd3df0d17c2c37c57029901ea7077a6e7a

Confirming that the problem in comment #7 is fixed in kwin 5.2.0.1.

Git commit a4791e629d6d0e6a988a222e70b82bb3555d3759 by Thomas Lübking.
Committed on 17/11/2015 at 20:30.
Pushed by luebking into branch 'master'.

Add rule to protect the focus on a window

This allows to pin the focus on certain window as well
as to more easily give it away on others (typically launchers)
Related: bug 185060
FIXED-IN: 5.5
REVIEW: 126059

M  +31   -7    activation.cpp
M  +5    -0    kcmkwin/kwinrules/ruleswidget.cpp
M  +1    -0    kcmkwin/kwinrules/ruleswidget.h
M  +296  -222  kcmkwin/kwinrules/ruleswidgetbase.ui
M  +7    -0    rules.cpp
M  +4    -0    rules.h

http://commits.kde.org/kwin/a4791e629d6d0e6a988a222e70b82bb3555d3759

assuming fixed. If still a problem, please reopen.