In general, the shell has no idea that the system is suspended. So, I see two likely possiblities here:

 1) The shell is crashing on suspend or resume, and takes a few seconds to start
 2) There's a graphic driver bug that shows the old contents of the screen

Do your logs (journalctl) show a shell crash?

There's also the case that we're not locking fast enough before suspend, even though we take the inhibitor.

(In reply to Owen Taylor from comment #1)
> In general, the shell has no idea that the system is suspended. So, I see
> two likely possiblities here:
> 
>  1) The shell is crashing on suspend or resume, and takes a few seconds to
> start
>  2) There's a graphic driver bug that shows the old contents of the screen

Hmm, so if I leave a window containing animation in view, it does appear static during the brief second that it is visible after resume.

> Do your logs (journalctl) show a shell crash?

Nothing that I can see. I can provide a log if you want.

do you only see this behavior when closing the lid ?

(versus alt-power button in the menu)

So just to expand on my line of thought a little bit...

Looking in the code, we throw down the screenshield in response to a "prepare-for-sleep" signal from logind.

logind will normally shoot the prepare-for-sleep signal before a small delay if there's a delay inhibitor in place.  systemd-inhibit shows there is indeed a delay inhibitor in place for the lock screen.

But looking in the code, there's an exception to the delay part:

        /* Tell everybody to prepare for shutdown/sleep */•
        send_prepare_for(m, w, true);•
•
        delayed =•
                m->inhibit_delay_max > 0 &&•
                manager_is_inhibited(m, w, INHIBIT_DELAY, NULL, false, false, 0, NULL);•
•
        if (delayed)•
                /* Shutdown is delayed, keep in mind what we•
                 * want to do, and start a timeout */•
                r = delay_shutdown_or_sleep(m, w, unit_name);•
        else•
                /* Shutdown is not delayed, execute it•
                 * immediately */•
                r = execute_shutdown_or_sleep(m, w, unit_name, error);•

so if delayed is false, logind won't give gnome-shell anytime to drop shield before suspend starts. So my theory is delayed == false if LidSwitchIgnoreInhibited=yes in /etc/systemd/logind.conf and so you're only seeing this problem when closing the lid.

I just tried closing the lid on my laptop and see the same delayed lock behavior.  I didn't see it using the menu.  I'll try changing /etc/systemd/logind.conf and see if that fixes it in a bit (bit busy with other stuff to reboot right now)

so just to follow up i tried changing logind.conf but the problem still happens. The behavior does change though: before the change suspend happened right away I think (though i'll need to reverify).  After the change it seems to wait the 8 seconds specified in the g-s-d power plugin (which is a blocking inhibitor not a delay inhibitor like the shell one).  So I think what may be going on is the max inhibitor delay may be 0 or something.  Since I can reproduce pretty readily, I guess i just need to set a break point on the above code and see what's going on. will look later.

i dug a little more into this and found out it's related to dpms.

First thing I noticed was this patch:

--- a/src/backends/x11/meta-monitor-manager-xrandr.c
+++ b/src/backends/x11/meta-monitor-manager-xrandr.c
@@ -926,4 +926,2 @@ meta_monitor_manager_xrandr_set_power_save_mode (MetaMonitorManager *manager,
 
-  DPMSForceLevel (manager_xrandr->xdisplay, state);
-  DPMSSetTimeouts (manager_xrandr->xdisplay, 0, 0, 0);
 }

made the problem go away.

Digging a little deeper I found this code in the settings daemon power plugin:

static void•
handle_suspend_actions (GsdPowerManager *manager)•
{•
        backlight_disable (manager);•
        uninhibit_suspend (manager);•
}•

(where backlight display forces DPMS off via the meta-monitor-manager api)

commenting out backlight_disable in this function also fixes it.

It's not clear to me why:

1) we would DPMS suspend the monitor before the laptop suspends. that should happen automatically when the machine suspends

2) why dpms suspending the monitor would cause drawing to freeze. Also, I don't see any frozen drawing when doing "xset dpms force suspend". so maybe the failure only happens if suspend occurs when the monitor is off.  another data point is putting "while true; do xset dpms force on; done" in a terminal makes everything work

a little irc chatter:

<Jasper> halfline, DPMS off == crtc disabled are often the same thing. I know airlied has something about this.
<halfline> note xset dpms force off doesn't exhibit the problem
<halfline> still a bit of a mystery
<Jasper> halfline, see the pre-this-commit message here: http://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/drivers/modesetting/drmmode_display.c?id=8affaade2c127ea08989c86e7d71cc9da3db1824
<Jasper> And I know that daniels fought a lot of page flipping + DPMS in his atomic work.
<daniels> (context?)
<Jasper> daniels, https://bugzilla.gnome.org/show_bug.cgi?id=753678#c7
<Jasper> daniels, somehow, DPMS is causing the X server not to render.
<halfline> so maybe what's happening is when the dpms gets turned the page flip fails and we keep the old back buffer around or something
<halfline> *off
<Jasper> Yeah, that sounds reasonable.
<Jasper> That's the unfortuante thing about X's rendering model.
<halfline> i do see a momentary screen freeze / jump if i just do pm-suspend and resume
<halfline> so the freeze isn't surprising, it's just that the freeze shows contents that are an animation behind

(In reply to Ray Strode [halfline] from comment #4)
> do you only see this behavior when closing the lid ?
> 
> (versus alt-power button in the menu)

Testing this now, it seems that the bug only appears if I suspend using alt-power button (it doesn't matter if I unsuspend using the physical power button or closing and then opening the laptop lid).

I would have sworn that it was happening when I suspended by closing the lid, but maybe I was imagining it. I'll let you know if that does happen in the future.

I have the lid switch disabled, so I can't easily test that.

If I use alt-power button, the screen goes black, then there's a flash of the lock screen, then the laptop turns off.  Resuming is at the lock screen.

If I use the suspend key on the keyboard, the screen goes immediately black and the laptop turns off.  Resuming shows the desktop for a second or two.

Both of these behaviours are consistently repeatable.

I consistently see it when closing/opening the lid (Gnome 3.16/Fedora 22), if there's any info I can gather, don't hesitate to ask.

Same here, saw this on my old HP laptop, and just started a new job and got a Lenovo T550, having the same trouble. If you need info let us know what you're after!

The same happens here with my new Thinkpad Yoga S1 running the latest arch linux kernel and gnome 3.16. When I resume from sleep I can see my desktop for 1-2 seconds before the screen lock appears. If you need more info this bug is easily reproducible several times in a row.

Chatted with Owen and Jerome Glisse about this today.

Current theory is this:

1) before locking the screen g-s-d tells gnome-shell to turn off the monitor
2) when the monitor is turned off vblank events are no longer delivered to the
X server
3) without vblank events, the screen never swaps buffers to show updates (and actually i think page flipping would fail anyway if it tried)

So probably the right approach is one of

1) make sure we don't dpms off the monitor until after we've finished the lock operation

2) paint a black frame before doing any dpms off operation

I can't give an opinion on which approach is better, but I am happy to test patches and I can reproduce at will.

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

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

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

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

I just want to add that this happens with Wayland too. Doesn't matter if using alt-power button, closing the lid or pressing physical power button.

It's a pity, that this bug is not fixed till today. For me it a real security/privacy problem, if somebody can see my last screen.

We share a laptop. When I put mine aside and somebody else wants to login, he/she will accentually see my last screen.

Hi,

I can still (GNOME 3.22) experience this with 2 different GPU (under wayland)

See also: bug #776051 and https://bugzilla.redhat.com/show_bug.cgi?id=1391126

Also note that a CVE has been assign to this bug: CVE-2016-1000002

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

(In reply to Ray Strode [halfline] from comment #14)
> So probably the right approach is one of
> 
> 1) make sure we don't dpms off the monitor until after we've finished the
> lock operation
> 
> 2) paint a black frame before doing any dpms off operation

Note that we have a user-visible setting in control-center that allows the user to configure the lock to occur a set amount of time after the screen turns off, e.g. five minutes. So (2) sounds safer, unless you have a plan to handle that problem too.

Hi All, I have the same problem here. In case it was useful for anyone to know, it started when upgrading from Fedora 24 to 25. I believe I had wayland disabled before. The issue happens *most* of times - say 4 out of 5 - but not always. It never happens when using an external display only - e.g. through my Lenovo T450s docking station. Occurrence is independent from the method I use to suspend the laptop.

I can confirm this happens on arch linux running gnome 3.24.2. It boggles me how such a security lapse is being treated as low priority... the bug was reported almost two years ago. What's the point of even having a screen lock if someone can see what I'm working on just by waking my computer from sleep??

I'm sure the gnome developers could solve this in a matter of two years if they really put their minds to it.

That's still a problem on 3.24.2 on Ubuntu with GNOME/wayland, not that it's not a video buffer/rendering issue on my laptop it takes several seconds after resume for the screen to lock and I can interact with the desktop during that time.

Shouldn't that be considered as a security issue?

I don't think there is any doubt that it is a security issue. The desktop is visile long enough that one can take a picture of it with a smartphone, for example.

Created attachment 358571 [details] [review]
MetaLauncher: Split up a long line

Created attachment 358572 [details] [review]
clutter/cogl: Add API to inhibit painting the stage actors

Allow mutter to inhibit painting the stage, and when doing so, instead
of painting the stage, clear the framebuffer, making sure it is
completely black.

Created attachment 358573 [details] [review]
native/launcher: Keep a pointer to the backend

Stop using the global singleton, just pass the backend to the launcher
instead.

Created attachment 358574 [details] [review]
backend/native: Minor coding style fix

Created attachment 358575 [details] [review]
native/launcher: Move pause/resume handling into helper

They only call pause/resume, but that will eventually change.

Created attachment 358576 [details] [review]
native/launcher: Get active state when launching

Instead of assuming it is TRUE, check that it is.

Created attachment 358577 [details] [review]
backends/native: Clear the framebuffer before suspending

While active, create a delayed sleep inhibitation, giving mutter a
chance to clear the framebuffer of all the monitor before letting the
computer go to sleep. When being signaled by logind that the system is
preparing to go to sleep, mutter will queue a paint that will clear the
framebuffers of all logical monitors. After having received the flip
callback, the inhibitation is dismissed. This results in no old
framebuffer content being displayed when coming back from sleep.

When inactive (i.e. user having switched user/VT), the inhibitation is
disabled; only when the session is active is the sleep inhibited.

This looks good but I think we need some mutter API to synchronize with screenShield.js in gnome-shell. In fact, there's logic there already which, in theory, shouldn't let this bug happen in the first place but it's missing one, perhaps crucial, piece - knowing when the lock screen as hit the frame buffer.

I guess one way forward would be removing the logind sleep inhibitor in screenShield.js and provide a similar API from mutter, built upon these patches, that gnome-shell can use instead.

Just curious. Would these patches find their way into the upcoming gnome 3.26 release?

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

Created attachment 362788 [details]
Individual monitor not locked

As pointed out in my referenced bug report, I sometimes see this depicted issue, where one screen gets unlocked, while the other remains locked. If this is another issue, please reopen my bug report.