Bug 306186

Created attachment 73620 [details]
screenshot of the situation after unlock

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.

@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

@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

"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

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.

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

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

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

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

Turned screenedges off, still same problem

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

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

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

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

Also present on Fedora 17.

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

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?

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)

Daybreak issue?

> 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

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

(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

> 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

(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

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

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

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.

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?

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

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

Created attachment 74913 [details]
Kwin Support Info

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

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

last dupe suggests daybreak relevance

Created attachment 74942 [details]
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?)

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

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

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

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

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

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