lockscreen: on autolock on suspend the fade does not complete before suspend leaving desktop partially visible for a short period on resume
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Unity |
Fix Released
|
High
|
Marco Trevisan (Treviño) | ||
unity (Ubuntu) |
Fix Released
|
High
|
Marco Trevisan (Treviño) |
Bug Description
When auto-locking as part of a suspend operation the lock screen still fades to opaque, this takes seconds and mid fade the suspend occurs. This means that on waking the machine the fade is still occurring and the desktop is partially visible potentially exposing information protected by the lock.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unity 7.1.2+14.
ProcVersionSign
Uname: Linux 3.13.0-17-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for `/apps/
CurrentDesktop: Unity
Date: Fri Mar 14 10:02:52 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-06-20 (266 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130618)
SourcePackage: unity
UpgradeStatus: Upgraded to trusty on 2013-11-10 (123 days ago)
Related branches
- Marco Trevisan (Treviño): Approve
- PS Jenkins bot (community): Approve (continuous-integration)
-
Diff: 1253 lines (+502/-275)19 files modifiedUnityCore/GnomeSessionManager.cpp (+19/-0)
UnityCore/GnomeSessionManagerImpl.h (+2/-0)
UnityCore/SessionManager.h (+1/-0)
lockscreen/CMakeLists.txt (+2/-1)
lockscreen/LockScreenAbstractShield.h (+1/-0)
lockscreen/LockScreenController.cpp (+217/-85)
lockscreen/LockScreenController.h (+28/-6)
lockscreen/LockScreenSettings.cpp (+24/-5)
lockscreen/LockScreenSettings.h (+4/-10)
lockscreen/LockScreenShield.cpp (+2/-0)
lockscreen/ScreenSaverDBusManager.cpp (+105/-0)
lockscreen/ScreenSaverDBusManager.h (+58/-0)
plugins/unityshell/src/unityshell.cpp (+7/-10)
plugins/unityshell/src/unityshell.h (+2/-0)
plugins/unityshell/unityshell.xml.in (+0/-20)
tests/data/external.gschema.xml (+15/-0)
tests/test_lockscreen_controller.cpp (+12/-135)
unity-shared/UScreen.cpp (+2/-3)
unity-shared/UScreen.h (+1/-0)
Changed in unity (Ubuntu): | |
importance: | Undecided → High |
Changed in unity: | |
importance: | Undecided → High |
tags: | added: rls-t-incoming |
Changed in unity: | |
status: | New → In Progress |
assignee: | nobody → Marco Trevisan (Treviño) (3v1n0) |
milestone: | none → 7.2.1 |
Changed in unity (Ubuntu): | |
status: | Confirmed → In Progress |
assignee: | nobody → Marco Trevisan (Treviño) (3v1n0) |
Changed in unity: | |
status: | In Progress → Fix Committed |
Changed in unity (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in unity: | |
status: | Fix Committed → Fix Released |
I've been closing all bugreports similar to this as a duplicate of LP: #49579 because all the time-based locking mechanisms are so brittle that none can be expected to work reliably.
Has this changed with the new Unity-based lockscreen? Will an application grabbing the mouse (indicators, menus, etc.) prevent the screen locker from locking? Or does the new Unity lock screen break those grabs in a fashion that locking can work reliably? (I'm skeptical.)
Thanks