Screen unlock password dialog stays visible and on top forever after unlocking

[Gard Spreemann]

After locking the screen for extended periods, and then unlocking, the password entry dialog stays frozen on screen on top of all other windows forever (or until desktop effects are switched off and back on).

The behavior is known upstream as KDE bug #306186 [1], whose discussion includes an analysis of the problem and a simple patch. The patch has been commited upstream [2], and also applies cleanly against kde-workspace 4:4.9.4-0ubuntu0.2. As far as three to four days of testing indicates, it fixes the problem for me. I did nothing else except add the upstream patch to debian/patches and appended its name to debian/patches/series.

[1] https://bugs.kde.org/show_bug.cgi?id=306186
[2] https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/a0aacdae08a6bdae0a30139d65ef92d5dff136e5

[Mikopp (mikopp)]

This does not happen all the time, but once it has only restarting KDE removes the dialog

1) lock your desktop
2) unlock you desktop

the dialog that you get to enter your password stays on the screen (see screenshot) and does not go away unless you kill KWIN (which obviously doesn't help really) or restart KDE all together.
Even locking and unlocking the screen afterwards doesn't improve the situation, even worse, I have a dual screen and after several lock/unlock I have that dialog in the middle of both my displays.

The dialog can not be clicked or interacted with, actually the windows below it can be clicked at, so it seems a drawing issue, the window doesn't seem to exist anymore.

Reproducible: Sometimes

Steps to Reproduce:
1) lock your desktop
2) unlock you desktop

[Mikopp (mikopp)]

Created attachment 73620
screenshot of the situation after unlock

[Mgraesslin (mgraesslin)]

I have seen this issue once but had no chance to properly investigate
it. An easy solution is to press Alt+Shift+F12 twice to suspend and
resume compositing.

[Thomas-luebking (thomas-luebking)]

@Michael:
- can you reproduce this somewhat often?
- do you unredirect fullscreen windows?
- does it remain if you export QT_NO_GLIB=1 from some ~/.kde/env script

[Mikopp (mikopp)]

@Martin
Thanks workaround works!
@Thomas
* Happens pretty regularly
* ??? not sure what you mean here. I have "maximized" windows but no fullscreen windows.
* Not tested, and as this is my work desktop I won't be able for a couple of days to do this, I will try to test it though

[Thomas-luebking (thomas-luebking)]

"kcmshell4 kwincompositing", last tab, "suspecnd comspositing for fullscreen windows" checkbox

How keen are you in using shell tools - do you think you can switch to VT1, there
export DISPLAY=:0

check for the password window (this has to happen really fast: move the mouse to trigger the locker, then move to VT1 where this command is already present or in history)
xwinfo -root -tree | grep "KDE Screen Locker"

and then monitor events for UnmapNotify
xev -root | grep -A1 UnmapNotify

and see whether the WinId found by the xwinfo command matches an UnmapNotification

[Juha Tiensyrjä (juha-tiensyrja)]

I can confirm this bug, happens to me also every couple of days or so both with 4.9.0 and 4.9.1 from Kubuntu packages.

[Thomas-luebking (thomas-luebking)]

much (MUCH) more important than "me too" would be to answer the questions of comments #3 & #5 ;-)

[Mikopp (mikopp)]

can you reproduce this somewhat often: Seems to happen every time that I leave my screen unattended on a multi screen, never happened to me when working on the notebook without external screens.

do you unredirect fullscreen windows: not sure what you mean, I do have fullscreen windows, in particular VirtualBox in seamless mode running sometimes. I have ""kcmshell4 kwincompositing", last tab, "suspecnd comspositing for fullscreen windows" checkbox" activated, does not change anything, problem still occurs.

- does it remain if you export QT_NO_GLIB=1 from some ~/.kde/env script
not tested yet, what other implications does this setttin have

[Mgraesslin (mgraesslin)]

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

[Thomas-luebking (thomas-luebking)]

Is this also reproducible if you turn all active screen edges off?

[Mikopp (mikopp)]

Turned screenedges off, still same problem

[Mikopp (mikopp)]

I can't seem to reproduce it if I force screen lock and then switch to VT1 and back. window id is the same between xwinfo and unmap then.

I see if I can reproduce it if the lock screen comes via normal screen timeout

[Thomas-luebking (thomas-luebking)]

(In reply to comment #12)
> I can't seem to reproduce it if I force screen lock and then switch to VT1
> and back.
you might be more lucky by ssh'ing into the machine.

> if you export QT_NO_GLIB=1 from some ~/.kde/env script
> not tested yet, what other implications does this setttin have

the setting makes Qt use the more straight forward unix event dispatcher instead of the glib one, exporting it to the global environment applies that to all Qt applications (after re-logging in)
The setting does not cause permanent changes (at least it's not supposed to, but oc. any application could check for that value, store "CrashMe=true" in it's settings and from now on just crash on start =)
Ie. the moment you remove the script, the alteration is gone with the next login.

[Mikopp (mikopp)]

ok could reproduce it now, xwinfo shows a different window id than the first unmap notify.

[Thomas-luebking (thomas-luebking)]

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

[Paul Fee (pfee)]

Also present on Fedora 17.

$ rpm -qf /usr/bin/kwin
kde-workspace-4.9.2-3.fc17.x86_64

[Mgraesslin (mgraesslin)]

I had the chance to have a look at a system which showed the same problem. Relevant part of supportInformation:

Currently Active Effects:
-------------------------
kwin4_effect_fade
kwin4_effect_blur

Unloading the fade effect, made the window go away.

@Thomas: could something trigger an incorrect unref in AnimationEffect?

[Thomas-luebking (thomas-luebking)]

From the screenshot (the window is opaque. did it perform a fedeout on your side at all?) i suspect a time problem, ie. AniData::startTime being much much bigger than QTime::currentTime()

Can you reproduce to test it? (or anyone else, including injecting debug out, ie. recompile)

[Thomas-luebking (thomas-luebking)]

Daybreak issue?

[Mgraesslin (mgraesslin)]

> From the screenshot (the window is opaque. did it perform a fedeout on your
> side at all?)
yes, it was completely opaque, which I found odd, given that fade was active.
> Can you reproduce to test it?
No pattern seen so far

[Eric Erfanian (eric-erfanian)]

I am able to reproduce this bug frequently by switching between two users.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #21)
> I am able to reproduce this bug frequently by switching between two users.

- do you use the fade effect?
- does it go away when disabling it?
- can you run some self compiled code with a debug out patch?

@Martin
i'm gonna write some dbus inspection code for the animationeffect class, basically print AniData for running animations on request

[Mgraesslin (mgraesslin)]

> i'm gonna write some dbus inspection code for the animationeffect class,
> basically print AniData for running animations on request
sounds good, I'm going to add something to the Scripted Effects

[Eric Erfanian (eric-erfanian)]

(In reply to comment #22)
> (In reply to comment #21)
> > I am able to reproduce this bug frequently by switching between two users.
>
> - do you use the fade effect?

Yes, both users use the fade effect.

> - does it go away when disabling it?

I'll have to try again when it appears. No luck reproducing it right now.

> - can you run some self compiled code with a debug out patch?

Sure; please just tell me what to checkout and any special compile / installation instructions,and then how to dump the debug information when it happens again.

>
> @Martin
> i'm gonna write some dbus inspection code for the animationeffect class,
> basically print AniData for running animations on request

[Eric Erfanian (eric-erfanian)]

Bug reappeared today. I disabled the fade effect in the account in desktop effects, and the lock screen dialogue went away.

[adaptee (adaptee)]

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

[Eric Erfanian (eric-erfanian)]

Interesting.Still on the same desktop session after disabling and then re-enabling the fade effect to get rid of the dialogue.

The dialogue still appears when switching between virtual desktops.

[Thomas-luebking (thomas-luebking)]

The window is onyl visible during the transition, i assume?
Are you using the fade desktop effect for the desktop transition?
Unloading the fade effect would not have unreferenced the window anyway (that is a bug) so i don't actually see why that should have removed the window in the first place.
-> does reloading the fade desktop effect have an impact?

[Eric Erfanian (eric-erfanian)]

(In reply to comment #28)
> The window is onyl visible during the transition, i assume?

Correct.

> Are you using the fade desktop effect for the desktop transition?

No, it is the cube animation. When I try the fade desktop effect it does not appear.

> Unloading the fade effect would not have unreferenced the window anyway
> (that is a bug) so i don't actually see why that should have removed the
> window in the first place.

Me neither, but disabling and re-enabling the fade effect worked!

> -> does reloading the fade desktop effect have an impact?

Negative; loading and unloading the fade desktop effect does not make the dialogue disappear from the desktop switching cube animation.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #29)

> No, it is the cube animation. When I try the fade desktop effect it does not
> appear.
Ok, de/activating the "fade desktop" effect would make no sense then, but it explains why the ref'd window suddenly shows up again.
Can you (unless you restarted meanwhile) provide the output of
qdbus org.kde.kwin /KWin supportInformation

and did i ask whether you can compile a patch into kwin?
In particular this one: https://git.reviewboard.kde.org/r/107063/
It will allow you to print extended debug data from the fade effect.

[Eric Erfanian (eric-erfanian)]

Created attachment 74913
Kwin Support Info

[Eric Erfanian (eric-erfanian)]

(In reply to comment #30)
> (In reply to comment #29)
>
> > No, it is the cube animation. When I try the fade desktop effect it does not
> > appear.
> Ok, de/activating the "fade desktop" effect would make no sense then, but it
> explains why the ref'd window suddenly shows up again.
> Can you (unless you restarted meanwhile) provide the output of
> qdbus org.kde.kwin /KWin supportInformation
>

Attached.

> and did i ask whether you can compile a patch into kwin?
> In particular this one: https://git.reviewboard.kde.org/r/107063/
> It will allow you to print extended debug data from the fade effect.

I'll look into it tonight and see if I can do it.

[adaptee (adaptee)]

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

[Thomas-luebking (thomas-luebking)]

last dupe suggests daybreak relevance

[Thomas-luebking (thomas-luebking)]

Created attachment 74942
Pot. fixing patch

Due to the possible daybreak relevance, attached is a patch that invokes also the date for the starttime of the effect..

Stupid question:
does the screensaver come with an STR (ie. the clock gets out of sync and then is resynced by ntp, causing a major jump?)

[Christoph-maxiom (christoph-maxiom)]

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

[Thomas-luebking (thomas-luebking)]

Git commit a0aacdae08a6bdae0a30139d65ef92d5dff136e5 by Thomas Lübking.
Committed on 03/11/2012 at 21:33.
Pushed by luebking into branch 'master'.

use QELapsedTimer to measure animation delay

QElapsedTimer uses a monotic clock on all relevant systems
and is thus invarant against date/time changes (while the
bug was likely caused by daybreaks)
REVIEW: 107250
FIXED-IN: 4.10

use monitc clock

M +3 -3 kwin/libkwineffects/anidata.cpp
M +1 -2 kwin/libkwineffects/anidata_p.h
M +12 -7 kwin/libkwineffects/kwinanimationeffect.cpp
M +6 -0 kwin/libkwineffects/kwinanimationeffect.h

http://commits.kde.org/kde-workspace/a0aacdae08a6bdae0a30139d65ef92d5dff136e5

[adaptee (adaptee)]

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

[Thomas-luebking (thomas-luebking)]

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

[Thomas-luebking (thomas-luebking)]

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

[Mgraesslin (mgraesslin)]

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

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Upstream patch." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Rohan Garg (rohangarg)]

Fix has been released for Trusty/Saucy/Precise ( via Kubuntu Backports PPA ).

Please refer to https://wiki.kubuntu.org/Kubuntu/KubuntuPPAs#Kubuntu_Backports to get more information about the Kubuntu Backports PPA.