| Summary: | plain windows do not get focus | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Harald Sitter <sitter> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aacid, hrvoje.senjan, john, marcus.moeller, simonandric5 |
| Priority: | NOR | Keywords: | regression |
| Version: | 5.0.0 | Flags: | mgraesslin:
ReviewRequest+
|
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/121197/ | ||
| Latest Commit: | http://commits.kde.org/kwindowsystem/6c04f136a9826ebce80ebf8dc9407ab2b43eba3b | Version Fixed In: | 5.5 |
| Sentry Crash Report: | |||
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. |
when starting plain qapp+qwidget apps from konsole(4) the new window never gets focus. this used to work in kwin(4). does not work with: - ksysguard started via konsole(4) or ctrl-esc shortcut - software-properties-kde (kubuntu pyqt5 application) applications that get focus correctly include: - systemsettings - usb-creator-kde (kubuntu pyqt5 application) minimal example code using pyqt5, when run from konsole(4) the window won't get focus: #!/usr/bin/python3 import sys from PyQt5 import uic from PyQt5.QtCore import * from PyQt5.QtGui import * from PyQt5.QtWidgets import * if __name__ == "__main__": app = QApplication(sys.argv) w = QWidget() w.show() sys.exit(app.exec_())