© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
This is a follow-on from bug 1375271( https:/
Expectation --
Given any one of the following actions:
- (from active desktop session) choosing "lock" from the Unity Panel power menu;
- (from locked session with screen turned off): using mouse movement, keystrokes, etc. to poke the screen awake; or
- (from suspend) initiating a resume,
...the expected result is to display an interactive lockscreen where the active user's password can be entered to access the session. On this particular machine, which is a touch hybrid, the lockscreen also includes the Onboard soft keyboard.
Observed behavior --
Instead of the lockscreen, each of these actions trigger the machine to display an image of the desktop/window session as it had been near the time of the lock or suspend. The cursor is visible and can be moved. The Unity Panel and Launcher usually appear as normal, although sometimes they are missing.
Nothing happens when the user attempts to interact with the visible session by mouse or keyboard input. Keyboard input will actually be fed to the lockscreen's password entry window, however. So blindly typing the password from the zombie GUI session image -- and then pressing "enter" -- will bring up an active, working session.
TTY session logins are available by the keyboard shortcuts ctrl-alt-F[number]. After pulling up one of these login screens (without actually logging in), then returning with ctrl-alt-F7, the lockscreen appears as expected.
Regression timeframe:
I believe this behavior began sometime during January 2015.
Replication:
This unexpected behavior takes place almost every time one of the listed actions is taken. During one period of testing on 2015-01-31, the bug disappeared for a few rounds of lock and unlock. However, it re-appeared shortly thereafter (I believe after the next restart or suspend-resume).
Video attachment:
A 1-minute video (.webm, no audio) is attached showing one form of this bug (simple lock-unlock). The main feed was taken from a smartphone, but the video also includes an inset of what SimpleScreenRec
On "lock", the actual screen became fully black. SSR, by contrast, recorded a black screen that included a clock in the top-right.
On mouse movement, the actual screen displayed the static image of the GUI/desktop session. SSR, by contrast, recorded a delayed but normal lockscreen appearing.
Security tag reasoning:
This bug displays a snapshot of recent screen contents from a user's GUI session even when the user has (actively or indirectly) locked the session. It also prevents a user from turning on the screen to command a user switch, go into TTY, etc. without displaying an image of her private GUI session.
Current graphics-related system info:
OEM: HP Envy x360 15t (convertible hybrid notebook)
CPU/GPU: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz | Intel HD Graphics 4400
OpenGL Core Profile version: 3.3 Mesa 10.5.0-devel
OpenGL Extensions version: 3.0 Mesa 10.5.0-devel
OS: Ubuntu 14.10 64-bit
Kernel: 3.16.0-29 generic
X Server: xorg-server 2:1.16.
pixman version: 0.32.4
Please let me know if there is further config information that would be helpful.
Upstream testing:
This is a production machine. I am willing to test pre-release packages provided the testing configurations are easy to revert (such as upstream kernels). I have been burned in the past with broken package systems and protracted config repairs after testing experimental graphics and video driver software. But I would still be willing give it a shot if there is a simple and reliable process to roll back the changes.