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

Bug #1102540 reported by Gard Spreemann
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KDE Base Workspace
Fix Released
High
kde-workspace (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

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

Tags: patch
Revision history for this message
In , Mikopp (mikopp) wrote :

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

Revision history for this message
In , Mikopp (mikopp) wrote :

Created attachment 73620
screenshot of the situation after unlock

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

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.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

@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

Revision history for this message
In , Mikopp (mikopp) wrote :

@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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

"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

Revision history for this message
In , Juha Tiensyrjä (juha-tiensyrja) wrote :

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.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , Mikopp (mikopp) wrote :

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

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , Mikopp (mikopp) wrote :

Turned screenedges off, still same problem

Revision history for this message
In , Mikopp (mikopp) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(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.

Revision history for this message
In , Mikopp (mikopp) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , Paul Fee (pfee) wrote :

Also present on Fedora 17.

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

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

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?

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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)

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

Daybreak issue?

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

> 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

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(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

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

> 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

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

(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

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

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

Revision history for this message
In , adaptee (adaptee) wrote :

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

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

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.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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?

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

(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.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(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.

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

Created attachment 74913
Kwin Support Info

Revision history for this message
In , Eric Erfanian (eric-erfanian) wrote :

(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.

Revision history for this message
In , adaptee (adaptee) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

last dupe suggests daybreak relevance

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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?)

Revision history for this message
In , Christoph-maxiom (christoph-maxiom) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , adaptee (adaptee) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

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

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

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

Revision history for this message
Gard Spreemann (gspreemann) wrote :
description: updated
Changed in kdebase-workspace:
importance: Unknown → High
status: Unknown → Fix Released
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Revision history for this message
Rohan Garg (rohangarg) wrote :

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.

Changed in kde-workspace (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.