| Summary: | Lockscreen focus issues | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreensaver | Reporter: | Martin van Es <bugs> |
| Component: | locker-qml | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | blackst0ne.ru, bugs5.kde.org, bugs, bugtracker+kde, burns7066, capitan.zap, clchildress, cnfourt, dataforce, dilfridge, george, infoman1985, inform, jaak, johu, jonathand131, juszczakn, kaddy080, korossy, mbriza, mgraesslin, MurzNN, olemarkus, oliver.henshaw, orion, rad.n, rivaldi8, robspamm, ryanrms, safa1996alfulaij, sanete, sb56637, serhiy.int, sine.nomine, sonni.norlov, stanislav.mamontov, stupor_scurvy343, tobias-inet00, tom+bugs.kde.org, tpr, trebor_x, tuomas, vleett, wilcobeekhuizen |
| Priority: | NOR | ||
| Version: | 4.11.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Martin van Es
2013-03-03 19:01:55 UTC
I am observing similar behavior - except that the first key stroke set the input in the password field. However, the first character is missed resulting in wrong password. When the unlock dialog is displayed, the password field shall be focused by default. Would be even better to also make the rest (background etc) non-focusable, if possible. Confirming, while using two screens, the dialog is sometimes in focus on one of them, or none. Sometimes I can type the password immediately (which is the preferred behavior as it's consistent with the previous version), sometimes it's possible after one character and sometimes I need to use mouse to choose the input bar. Confirming. After upgrading to 4.10.0 I cannot unlock screen without a mouse. Well, maybe it's slightly different, the window with a field doesn't even show until I click "Leave Screensaver". Still reproducible on 4.10.1. I can sort of confirm this on openSUSE 12.3 with KDE 4.10.0. In my case, after resuming from suspend I see the lock screen without focus. However, when I move the mouse or type it key, the password field gets focus. I still don't like it this way. It should be automatically focuses as soon as the screen appears. Can we get this bug marked as confirmed please? Thanks. Confirming - sometimes it works, but not usually after suspend. I run a dual monitor setup, so sometimes it focuses the last active monitor, or neither. Now I just upgraded to 4.10.1 on openSUSE 12.3, and it's behaving differently. I still have to move the mouse or press the key to get the lockscreen to appear after resuming from suspend. Sometimes it doesn't show the cursor, but it usually seems to have focus at least. However, there is now a regression -- after resuming it shows the desktop for a few seconds before blinking and going black again, thus briefly exposing whatever was on the screen before suspend. With 4.10.0 it never showed the desktop before suspend. (In reply to comment #7) > ... However, there is > now a regression -- after resuming it shows the desktop for a few seconds > before blinking and going black again, thus briefly exposing whatever was on > the screen before suspend. With 4.10.0 it never showed the desktop before > suspend. Confirming this. Sometimes it takes up to some 10s after resume for the screen to be cleared again, exposing its contents. Using screensaver for locked screen. (In reply to comment #7) > Now I just upgraded to 4.10.1 on openSUSE 12.3, [...] > However, there is > now a regression -- after resuming it shows the desktop for a few seconds > before blinking and going black again, thus briefly exposing whatever was on > the screen before suspend. With 4.10.0 it never showed the desktop before > suspend. This is bug #313123 - by my best understanding this likely only happens on systems with systemd ( >= 195) where we use it (really login) to suspend and get bitten because it suspends immediately (unlike upower) and we're not prepared for that. I'm guessing opensuse now has new enough logind to trigger the bug? Well. Confirming on Gentoo with udev-[190-200]. Desktop boot without password with locked screen. Focus is lost after circa 1 second from showing password dialog. Gentoo ~amd64 from first kde with locker-qml release. Related to the issues above, you cannot even focus the password field using the keyboard. The "P" in Password is underlined, but pressing Alt+P does not select the field, and pressing Tab repeatedly does not cycle through the controls. (But pressing Alt+S and Alt+L do correctly work for the "Switch User" and "Unlock" buttons.) I also can't tell whether the field is selected until I try to type a password, since the field has no text cursor even when it is focused. [Just upgraded to 4.10.1 on Gentoo; already had udev 200 installed, if that matters.] I also have this on Gentoo with 4.10.1 and 4.10.2. Sometimes the password field becomes active after pressing Enter (which results in 'Incorrect password' message), sometimes only mouse selection works. This sucks. And 4.9 is already removed from Portage, so I cannot just rollback to previous version. I can confirm this bug on Arch Linux with KDE 4.10.2. As a workaround I just press enter when a password is asked, resulting in an incorrect password message, followed by me entering the password. Still broken with the new KDE 4.10.3 update on openSUSE 12.3 i586. Upon resume, it shows a LOT of scary looking console spam flying by, and then it shows the desktop for several seconds, then briefly shows the lockscreen, then a black screen with mouse pointer. After moving the mouse, the lockscreen appears and is ready for input. The password field has focus, but it shouldn't be necessary to move the mouse. Additionally bug #313123 and #312828 are still rearing their ugly heads. You do not need to press enter and get a wrong password, you can use Escape to toggle the Password input dialogue. Unfortunately, the lockscreen does not disappear on my system since the 4.10.3 archlinux KDE update after entering the right password, the screen stays black and the input dialogue disappears. I do not have any widgets there and the system requires a X restart. I can also confirm this on Fedora 18 with KDE 4.10.3. I have 4 screens and rarely (perhaps only 1 in 10 times) will the password field have focus. I've tried the tricks of hitting Enter or Esc to "toggle" the dialog and none of these have worked for me since 4.10 first came out. If I see any pattern, it's that perhaps the duration of the lock affects the likelihood of the focus being correct: the longer the screens have been locked the less likely that focus will be correct. Very short lock tests (those useless in real life) quite often do work yet longer locks, say over a lunch hour or even a 20m break for a walk will almost never work. (By "work" I mean get focus by default.) Confirm this issue on Kubuntu 13.04. Focus is always lost after changing language (via Alt+Shift), and sometimes without this action on unlock I see lost focus. Still a problem. Using openSuSE 12.3 with 4.10.5. If I have my mouse cursor over my primary screen, the password box receives focus, however if I have my mouse on my other monitor and lock the screen, neither receive focus, and I have to manually click one of them to login. Quite a pain. I can confirm this bug on Kde 4.10.5 on Gentoo and Kde 4.11 on Kubuntu C'mon guys... this bug has been around for too long now... I know it is minor, but it is also significant and easy to fix quickly by a Kde developer. This shouldn't still be an issue over 2 generations of Kde major releases... *** Bug 317585 has been marked as a duplicate of this bug. *** 314720 seems to be duplicate too. Still there in KDE SC 4.11.2 (Ubuntu PPA packages) I can also confirm this behavior on OpenSUSE 13.1 with KDE 4.11. We just need the unlock dialog box to have focus. In Kubuntu 13.10 using KDE 4.11.2, this bug has significantly worsened. Not only does the unlock dialog text box not have the focus, but now the application that had the focus before the screen locking occurred has still the focus. Thus, if you (admittedly carelessly) enter your password in the lockscreen without checking the screen and hit enter, you might just send your password to one of IM contacts. In my opinion, this is an extremely severe bug that should be fixed immediately. If this is extremely difficult, then I at least like to ask to develop a workaround that allows us to use the old lock screen, which does not show this intolerable behaviour. Confirmed. Still exists in 4.11.2. Confirmed in 4.11.2 - Fedora 19 I can't reproduce it in 4.11.3 version. Tryed on two PCs. It ain't here anymore? I still see in on Fedora 19 with 4.11.3 and two monitors. Likewise, confirming on Debian 4.11.3 with two monitors. This could be a dupe of https://bugs.kde.org/show_bug.cgi?id=319935 or https://bugs.kde.org/show_bug.cgi?id=311188 ? The latter is fixed in 4.11.4, so please do test. I confirm this behavior in KDE 4.11.3 and Fedora 13. Still an issue with Kde SC 4.12 RC with Ubuntu PPA packages. Comment 31: I meant Fedora 19, instead of Fedora 13. Confirm on Kde SC 4.12 RC this bug is still exist too. https://bugs.kde.org/show_bug.cgi?id=319935 has unconfirmed status, so better is to mark https://bugs.kde.org/show_bug.cgi?id=319935 as dupe of this issue. So many duplicates, so easy to reproduce bug, but it's still not fixed in ALMOST a year. The bug can be fixed in 3 lines changed something like that: http://bugsfiles.kde.org/attachment.cgi?id=80256 It definitely shouldn't take a year to make a 3-lines-patch. There's a reviewboard request https://git.reviewboard.kde.org/r/113697/ though not so many comments, so haven't dared to commit it. And that's basically the same as your patch, but it is more a fix to the bug #319935. Don't know what are the main causes of this bug, could be multiscreen related (which should be now fixed already) or something else, as people don't specifically state they have pressed alt to get the accelerators... There's also related bugs, so that patch is not simply enough for all of it. The forementioned "first character eaten" bug is caused by a completely another bug (namely that screensaver process eats the first input event). Teemu Rytilahti, thank you for response. It wasn't my patch, I've just found it in thread of duplicate #319935. I got it, that there can be some other problems, which are more complicated, but adding fix for focus-losing on pressing ALT key (layout change with Alt+Shift) will be appreciated. It's easy and it's relevant. *** Bug 328412 has been marked as a duplicate of this bug. *** Also confirmed on openSuse 12.3 with KDE 4.10. Drives me mad every time I unlock my machine. Pretty much the only bug that's still causing me issues. No problems anymore with KDE 4.13. Problems seams to have been resolved in KDE 4.11.5 on gentoo Works fine on current Kubuntu 14.04 also. Confirm , now works with kubuntu 14.04 64 bit and kde 4.13. Also for me in Kubuntu 14.04 and dual monitor Confirm fixing lost focus via Move mouse - now works well with kubuntu 14.04 64 bit and kde 4.13. But second part of lockscreen focus issue with switching layout, described at https://bugs.kde.org/show_bug.cgi?id=319935 issue - is still active on kubuntu 14.04 64 bit and kde 4.13. Not working here. Password box losses focus when switching languages (I use English and Arabic for example). ArchLinux KDE 4.13 Given comment #40 to #45 the issue seems to be fixed. I'm still seeing this issue with KDE 5.4.3 in Kubuntu 15.10 (packages from KDE PPA). I can reproduce it in the following way: 1. Open a terminal. 2. Run "sleep 10; dolphin". 3. Lock the screen before the sleep times out. The password field will be focused. 4. The sleep time expires and Dolphin is run, which provokes the password field to lose focus. This seems to happen with any window that is opened while the screen is locked. > I'm still seeing this issue with KDE 5.4.3 in Kubuntu 15.10 (packages from KDE PPA). The bug described in this report was for 4.x. Unfortunately it sneaked back in with 5.x. I recently investigated it and found a solution in https://git.reviewboard.kde.org/r/124966/ - this change will be available in Plasma 5.5, which means it's not yet available in the version you are using. |