After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753678 - (CVE-2016-1000002) Desktop temporarily visible after wake up from suspend
(CVE-2016-1000002)
Desktop temporarily visible after wake up from suspend
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: lock-screen
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
safety,triaged
: 749598 757868 758729 766880 776051 789289 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-08-16 12:18 UTC by Allan Day
Modified: 2021-07-05 14:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
MetaLauncher: Split up a long line (985 bytes, patch)
2017-08-28 09:00 UTC, Jonas Ådahl
none Details | Review
clutter/cogl: Add API to inhibit painting the stage actors (4.32 KB, patch)
2017-08-28 09:00 UTC, Jonas Ådahl
none Details | Review
native/launcher: Keep a pointer to the backend (3.25 KB, patch)
2017-08-28 09:00 UTC, Jonas Ådahl
none Details | Review
backend/native: Minor coding style fix (959 bytes, patch)
2017-08-28 09:01 UTC, Jonas Ådahl
none Details | Review
native/launcher: Move pause/resume handling into helper (1.65 KB, patch)
2017-08-28 09:01 UTC, Jonas Ådahl
none Details | Review
native/launcher: Get active state when launching (1.27 KB, patch)
2017-08-28 09:01 UTC, Jonas Ådahl
none Details | Review
backends/native: Clear the framebuffer before suspending (14.59 KB, patch)
2017-08-28 09:01 UTC, Jonas Ådahl
none Details | Review
Individual monitor not locked (161.56 KB, image/jpeg)
2017-11-02 01:43 UTC, Frank
  Details

Description Allan Day 2015-08-16 12:18:03 UTC
I've been experiencing this for a little while - when I wake up my laptop from suspend (by opening the lid), it take a second or two for the lock screen to kick in. During this time, the desktop is visible.

This is on 3.16.2 with Fedora 22. The machine is a Thinkpad T440s.
Comment 1 Owen Taylor 2015-08-17 15:02:39 UTC
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?
Comment 2 Jasper St. Pierre (not reading bugmail) 2015-08-17 15:12:25 UTC
There's also the case that we're not locking fast enough before suspend, even though we take the inhibitor.
Comment 3 Allan Day 2015-08-17 20:33:50 UTC
(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.
Comment 4 Ray Strode [halfline] 2015-08-31 12:52:46 UTC
do you only see this behavior when closing the lid ?

(versus alt-power button in the menu)
Comment 5 Ray Strode [halfline] 2015-08-31 13:02:07 UTC
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)
Comment 6 Ray Strode [halfline] 2015-09-02 00:18:25 UTC
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.
Comment 7 Ray Strode [halfline] 2015-09-02 18:00:44 UTC
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
Comment 8 Ray Strode [halfline] 2015-09-02 18:35:46 UTC
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
Comment 9 Allan Day 2015-09-10 14:21:37 UTC
(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.
Comment 10 Samuel Sieb 2015-09-14 16:07:06 UTC
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.
Comment 11 Dave Allan 2015-09-14 18:03:37 UTC
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.
Comment 12 jamesrstocker@gmail.com 2015-09-14 19:12:23 UTC
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!
Comment 13 Patrick Guilbert 2015-09-18 12:45:08 UTC
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.
Comment 14 Ray Strode [halfline] 2015-09-25 17:50:31 UTC
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
Comment 15 Dave Allan 2015-09-30 10:56:43 UTC
I can't give an opinion on which approach is better, but I am happy to test patches and I can reproduce at will.
Comment 16 Ray Strode [halfline] 2015-11-10 15:25:54 UTC
*** Bug 757868 has been marked as a duplicate of this bug. ***
Comment 17 Michael Catanzaro 2016-01-11 19:29:31 UTC
*** Bug 749598 has been marked as a duplicate of this bug. ***
Comment 18 Michael Catanzaro 2016-01-11 22:45:33 UTC
*** Bug 758729 has been marked as a duplicate of this bug. ***
Comment 19 Ray Strode [halfline] 2016-05-25 19:08:50 UTC
*** Bug 766880 has been marked as a duplicate of this bug. ***
Comment 20 Eddy Castillo 2016-08-10 19:12:28 UTC
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.
Comment 21 Peter Sonntag 2016-08-10 20:23:10 UTC
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.
Comment 22 Laurent Bigonville 2016-12-26 18:42:49 UTC
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
Comment 23 jc 2016-12-26 21:27:30 UTC
*** Bug 776051 has been marked as a duplicate of this bug. ***
Comment 24 Michael Catanzaro 2017-02-22 15:26:57 UTC
(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.
Comment 25 Gianfranco Cecconi 2017-03-21 07:12:42 UTC
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.
Comment 26 harish.hyma 2017-07-27 09:25:22 UTC
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.
Comment 27 Sebastien Bacher 2017-08-22 15:25:12 UTC
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?
Comment 28 Gianfranco Cecconi 2017-08-22 15:28:04 UTC
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.
Comment 29 Jonas Ådahl 2017-08-28 09:00:39 UTC
Created attachment 358571 [details] [review]
MetaLauncher: Split up a long line
Comment 30 Jonas Ådahl 2017-08-28 09:00:48 UTC
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.
Comment 31 Jonas Ådahl 2017-08-28 09:00:58 UTC
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.
Comment 32 Jonas Ådahl 2017-08-28 09:01:07 UTC
Created attachment 358574 [details] [review]
backend/native: Minor coding style fix
Comment 33 Jonas Ådahl 2017-08-28 09:01:16 UTC
Created attachment 358575 [details] [review]
native/launcher: Move pause/resume handling into helper

They only call pause/resume, but that will eventually change.
Comment 34 Jonas Ådahl 2017-08-28 09:01:24 UTC
Created attachment 358576 [details] [review]
native/launcher: Get active state when launching

Instead of assuming it is TRUE, check that it is.
Comment 35 Jonas Ådahl 2017-08-28 09:01:35 UTC
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.
Comment 36 Rui Matos 2017-08-28 12:50:50 UTC
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.
Comment 37 harish.hyma 2017-08-28 13:40:27 UTC
Just curious. Would these patches find their way into the upcoming gnome 3.26 release?
Comment 38 Florian Müllner 2017-10-21 17:28:36 UTC
*** Bug 789289 has been marked as a duplicate of this bug. ***
Comment 39 Frank 2017-11-02 01:43:36 UTC
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.
Comment 40 Kevin Walker 2018-03-16 16:02:49 UTC
has any progress been made finding a fix for the screen visible on resume from sleep bug?
Comment 41 Kevin Walker 2018-03-16 16:10:51 UTC
Can anyone point me to information on the Linux Kernel suspend process or how it is triggered?, by process I mean logical process and not running task etc. I am looking to find a way of launching a script on suspend, do some things and then suspend.
Comment 42 henry78 2018-03-16 19:26:08 UTC
I haven't had this issue for some time (+1 yr), so it's fixed here.

Regarding the "script on suspend", I'd use systemd. I see two possiblities: Place a script unter /lib/systemd/system-sleep/ (maybe not very pretty). Or add a service with ("Before=suspend.target" or "Before=sleep.target"). I use the latter variant to get delayed-hibrnatios (see https://bbs.archlinux.org/viewtopic.php?pid=1420279#p1420279).

Feel free to contact me directly, I'll unsubscribe from this bug, as it's fixed for me.
Comment 43 Jonas Ådahl 2018-03-17 00:24:59 UTC
(In reply to Kevin Walker from comment #41)
> Can anyone point me to information on the Linux Kernel suspend process or
> how it is triggered?, by process I mean logical process and not running task
> etc. I am looking to find a way of launching a script on suspend, do some
> things and then suspend.

We rely on logind to tell us when the computer is about to go to sleep. When that happens the screen shield is triggered to lock and while doing that, it'll create a sleep inhibitation, causing logind to wait with actually suspending until either until uninhibited or after a timeout.

Relevant code:

https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/misc/loginManager.js#L105

https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/ui/screenShield.js#L728
Comment 44 Samuel Sieb 2018-03-17 01:39:42 UTC
Could it be that the timeout is too short?  My hard drive was getting slow and the laptop was low on RAM so maybe that caused gnome-shell to take too long to get the shield down.  Now that I have an SSD and more RAM I probably won't see this problem again.  My other laptop that has an SSD also never had this.
Comment 45 Kevin Walker 2018-03-17 17:21:06 UTC
(In reply to Jonas Ådahl from comment #43)
> (In reply to Kevin Walker from comment #41)
> > Can anyone point me to information on the Linux Kernel suspend process or
> > how it is triggered?, by process I mean logical process and not running task
> > etc. I am looking to find a way of launching a script on suspend, do some
> > things and then suspend.
> 
> We rely on logind to tell us when the computer is about to go to sleep. When
> that happens the screen shield is triggered to lock and while doing that,
> it'll create a sleep inhibitation, causing logind to wait with actually
> suspending until either until uninhibited or after a timeout.
> 
> Relevant code:
> 
> https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/misc/loginManager.
> js#L105
> 
> https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/js/ui/screenShield.
> js#L728

Thanks Jonas, I have looked at the snippets, this seems quite high level from the actual methods doing the suspend. 

Digging around in the PM side of Linux, there appears to be scripts used for suspend, is a suspend script at OS level called after you have passed a message to logind? Are you dropping the screen shield before this. Would love to see a simple flowchart of stages of shutdown, sleep and hibernate... ;-)
Comment 46 Kevin Walker 2018-03-17 18:00:38 UTC
(In reply to Samuel Sieb from comment #44)
> Could it be that the timeout is too short?  My hard drive was getting slow
> and the laptop was low on RAM so maybe that caused gnome-shell to take too
> long to get the shield down.  Now that I have an SSD and more RAM I probably
> won't see this problem again.  My other laptop that has an SSD also never
> had this.

I did think about the timeout value, it is as if Gnome doesn't have enough time to drop the screen shield...

Where is this value located?
Comment 47 Ray Strode [halfline] 2018-03-17 18:24:12 UTC
Kevin, would be good if you could try the "while true; do xset dpms force on; done" thing from comment 7 to see if the issue might be comment 14
Comment 48 Kevin Walker 2018-03-17 20:11:05 UTC
So comment out the disable backlight statement and recompile?

I can do that - Just point me to git repo etc.. Is it possible to replace just the binary once compiled or just do the usual make install?

It does look as if the display turns off before gnome gets a chance to blank the screen. If we are sleeping, turning the backlight off doesn't seem to be needed and probably blocks blanking the screen (i think this was identified before) and it will turn off when the system drops into a low power state, so I can see the logic of how this fixes it.


Kevin
Comment 49 Ray Strode [halfline] 2018-03-17 23:51:19 UTC
really i just want you to open a terminal and run:

while true; do xset dpms force on; done

then lock the screen while the command is running and see if the problem goes away.  no need to recompile anything.  if you do want to recompile, you could give Jonas's patch a try
Comment 50 Kevin Walker 2018-03-22 12:17:33 UTC
So with this running in a terminal, both hibernation and sleep still exhibit the same problem when waking up and returning to the unlock screen. The open desktop is briefly visible
Comment 51 Kevin Walker 2018-03-31 20:15:47 UTC
ok, i will try Jona's patch
Comment 52 Ray Strode [halfline] 2018-03-31 23:55:25 UTC
thanks for all the testing
Comment 53 ret63244 2018-07-11 12:22:41 UTC
Hi, i have this bug on ubuntu 18.04 using gdm 3.28.2 and gnome-shell 3.28.2. Using "while true; do xset dpms force on; done" prevents the problem. 

I also tried to apply jonas patch (comment 35) on the ubuntu 3.28.2 source, but it fails for me with:

    patching file src/backends/native/meta-backend-native.c
    Hunk #1 FAILED at 64.
    Hunk #2 succeeded at 623 (offset -84 lines).
    Hunk #3 succeeded at 743 (offset -88 lines).
    1 out of 3 hunks FAILED -- saving rejects to file src/backends/native/meta-backend-native.c.rej
    patching file src/backends/native/meta-backend-native.h
    patching file src/backends/native/meta-launcher.c
    Hunk #1 FAILED at 51.
    Hunk #2 succeeded at 107 (offset -3 lines).
    Hunk #3 FAILED at 294.
    Hunk #4 FAILED at 307.
    Hunk #5 succeeded at 317 (offset -17 lines).
    Hunk #6 succeeded at 388 (offset -18 lines).
    Hunk #7 FAILED at 430.
    Hunk #8 succeeded at 427 with fuzz 2 (offset -20 lines).
    Hunk #9 succeeded at 443 (offset -20 lines).
    Hunk #10 succeeded at 475 (offset -20 lines).
    4 out of 10 hunks FAILED -- saving rejects to file src/backends/native/meta-launcher.c.rej
    patching file src/backends/native/meta-launcher.h
    Hunk #1 succeeded at 43 (offset -3 lines).
    patching file src/org.freedesktop.login1.xml
    patch unexpectedly ends in middle of line

probably has to be rebased to 3.28.2, or?

I have to add that i use S0i3 sleep (with the kernel parameter "acpi.ec_no_wakeup=1") and not s3, since my laptop (x1 carbon gen6) only supports this modern standby... 

Moreover, this problem does only occur using the X session and not in the wayland session.

I there a quick and dirty temporary solution like commenting the DPMS lines like proposed in comment 7, or does this cause side effects?
Comment 54 Jason Knight 2018-11-12 19:42:37 UTC
Hello,

I am using Ubuntu Budgie and I used the following to work around this issue:

#disable display power management
xset -dpms

Then I can use a single press of my laptop's power button OR click the suspend action in the user menu to clear and lock the screen and THEN suspend the session.

With dpms on (check "xset q"), both the power button and the ui suspend button cause the session to end BEFORE the screen has been locked. This causes the previous session's final screen contents to be shown the user upon resume.

With dpms on, closing the lid of the laptop WITHOUT pressing the power button or clicking suspend causes the laptop's screen to lock and STAY ON while the lid is closed.

Either dpms should be disabled by default, and the screen should properly shut off when the lid is closed, OR dpms should be enabled by default but the screen should properly blank & lock before the session is suspended.
Comment 55 GNOME Infrastructure Team 2021-07-05 14:41:17 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.