desktop contents briefly visible on resume from suspend before lock dialog
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
New
|
Undecided
|
Unassigned | ||
unity-2d |
Confirmed
|
High
|
Unassigned | ||
gnome-screensaver (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
i3-wm (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
unity-2d (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This seems like a recent regression on Oneiric (or perhaps I haven't noticed it before):
On resume from suspend, the contents of the desktop are often briefly visible before being hidden behind the lock screen. This is a security problem if there happens to be sensitive information on the screen.
=====Analysis from mdeslaur=====
This is likely what happens:
1- Something grabs mouse: ie: virtual machine window, or GTK menu in an application or an indicator
2- Screensaver attempts to start, but cannot get exclusive lock on mouse
3- DPMS turns monitor black
4- User moves mouse, which turns the screen back on
5- Mouse movement causes mouse to get ungrabbed by vm window or gtk menu
6- Screensaver can now grab mouse, and starts
This is all related to the fact that X does not have an API that will let the screensaver tell an application to release mouse and keyboard grabs.
summary: |
- lock resume + desktop contents briefly visible on resume from suspend before lock + dialog |
Changed in unity-2d: | |
importance: | Undecided → High |
Changed in unity-2d: | |
status: | New → Confirmed |
Changed in unity-2d (Ubuntu): | |
status: | New → Confirmed |
description: | updated |
affects: | unity → compiz |
tags: | added: 15.10 |
this does seem to be 2d specific.