+++ This bug was initially created as a clone of Bug #677345 +++ Description of problem: when resuming from suspend, the desktop with all its contents before suspending are visible for a short moment before the screen goes blank and one is able to enter his/her password to the session lock window. this poses a slight security risk as there is enough time to read parts of the content. This is different from Bug #677345 because it occurs in Gnome, not KDE. Steps to reproduce: 1. Suspend system (S3 suspend) 2. Resume system Actual results: The desktop and all of its contents are visible for a few seconds before the lock screen appears. Expected results: The lock screen appears immediately after the system resumes.
I think it's a bug in gnome-session or gnome-screensaver, I'm not sure. A solution for this (in gnome-power-manager or whatever else) might be locking the screen before actually suspending the system. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #1) > I think it's a bug in gnome-session or gnome-screensaver, I'm not sure. Thank you for your quick response! Sorry if I filed it under thee wrong component. I wasn't sure either. Is there some way that I could find out?
eek, still there in f15-gnome as of gnome-session-3.0.1-2.fc15 (x86_64) gnome-screensaver-3.0.0-1.fc15 (x86_64) gnome-power-manager-3.0.2-2.fc15 (x86_64) kernel-2.6.40-4.fc15 (x86_64) i suggest raising the severity on this.
I'm also experiencing this bug. gnome-session-3.0.1-2.fc15 (x86_64) gnome-screensaver-3.0.0-1.fc15 (x86_64) gnome-power-manager-3.0.2-2.fc15 (x86_64) kernel-2.6.40-3.fc15 (x86_64) xorg-x11-server-Xorg-1.10.3-1.fc15 (x86_64) xorg-x11-drv-ati-6.14.1-2.20110525gitfe5c42f51.fc15 (x86_64) AMD Radeon HD 3200 graphics card smolt profile: http://www.smolts.org/client/show/pub_3485f516-bbd4-457e-8108-a1bfc65ff712 Both KDE and GNOME users are reporting similar symptoms, so perhaps the bug is related to the kernel or to X? I'd be happy to file an upstream bug if anyone can figure out what component to file against! :D
You need gnome-settings-daemon 3.1.90 if you're using f16. I'll look at backporting the fix to f15 later this week.
A fix for F15 would be fantastic. Thanks Richard!
hmm just had this happen with f16-gnome-rc2: gnome-settings-daemon-3.2.1-4.fc16 (64bit) poop.
still happens with fresh install of f16-gnome release: gnome-settings-daemon-3.2.2-1.fc16 (64bit) (x86_64)
confirming, same for me: Name : gnome-settings-daemon Arch : x86_64 Version : 3.2.2 Release : 1.fc16
similar bugs for duplicateness consideration: https://bugzilla.redhat.com/show_bug.cgi?id=677345 https://bugzilla.redhat.com/show_bug.cgi?id=682132 https://bugzilla.redhat.com/show_bug.cgi?id=713640 https://bugzilla.redhat.com/show_bug.cgi?id=714784 https://bugzilla.redhat.com/show_bug.cgi?id=748560 https://bugzilla.redhat.com/show_bug.cgi?id=761074 https://bugzilla.redhat.com/show_bug.cgi?id=697199
hadnt seen in fc17alpha-gnome at all until got some updates of last day or so. not sure if its cause but those updates included gnome-settings-daemon-3.3.92-1.fc17.x86_64 currently running: gnome-settings-daemon-3.3.92-1.fc17.x86_64 gnome-session-3.3.92-2.fc17.x86_64) gnome-screensaver-3.3.92-1.fc17.x86_64 gnome-power-manager-3.3.92-1.fc17.x86_64 kernel-3.3.0-1.fc17.x86_64
Just saw this bug on an up-to-date (as of June 10) f17.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is still present now in Fedora 18. Can someone change the affected version, or should I open a new bug ?
The problem persists in F19. Did a little investigation, it looks like the screen gets locked after the system resumes, i.e. gnome screensaver did not manage to lock the screen before going to suspend. Since suspend is controlled by systemd now, the DE can inhibit systemd by either completely blocking suspend or delaying it by some amount of time (5s by default). Seems like the 5s delay is too short if system is loaded. The whole sync by sleep approach is inherently broken by design anyway. For those affected by the problem, you can try changing this entry in /etc/systemd/logind.conf and rebooting the system seems to make things better (at least on my system): [Login] ... InhibitDelayMaxSec=15
Can I vote for this somehow...
Can I vote for this somehow... It should be a high priority security issue... I really don't want to install xscreensaver ;)
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I still see this sometimes on my laptop with F19.
I confirm this is still an issue for me with F20, it happens almost every time when I resume from suspend.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Got a report of this happening in F22. And, it looks like this one has been getting kicked around for a while. Reopening....
This bug is present on two laptops with Fedora 22 Workstation. Both machines are Intel x86_64 with integrated Intel graphics. The bug is triggered in two ways. 1) Closing and reopening the laptop lid. 2) Suspending and waking the laptop with the power button. The bug is not triggered when the screen locks from timing out. My laptop is a Dell Inspiron from ca. 2012. The other laptop is an "old" (as described by my friend) HP laptop. I can provide other information if needed. I do not recall experiencing the bug in F21.
I have this issue on a Thinkpad x220 with F22. For me, it is only triggered on wake after closing and opening the laptop lid. I don't see the bug when sleeping and waking through the GUI (Gnome) or when using the laptop power button.
Just another data point: I had this bug with Fedora 19 but it appears to be fixed since I upgraded to Fedora 21 in January. I say it "appears" to be fixed because, no matter how long my system has been running, my system now resumes instantly from suspend so if it displaying anything before the lock screen, it happens too briefly to detect. (With Fedora 19 the delay before the lock screen was displayed increased with time since system restart upwards of thirty seconds after a few weeks.) I'd be happy to provide more details if it's useful to hear from a system that did suffer from this bug and no longer does.
I see this issue on Fedora 22 under Gnome on my ThinkPad Edge E531 when resuming from a suspended state. This was not an issue for me on this laptop with Fedora 20 or 21, it has only appeared in 22. The delay is long enough that it's possible to read part of the existing screen contents before the screen lock takes over.
If it's of any use, I am having this issue as well on a Dell Latitude E5540. It only seems to occur when suspending using the power button or closing the lid. When using the button in the Gnome shell, the issue doesn't occur. Some extra information that might be useful; I've had F21 installed on the same machine and I didn't experience this issue. I started experiencing this issue since I did a clean install of F22 about two weeks ago. It takes about a second or so before the lock screen appears. If there's anything I can do (provide logs or something), just ask and I'll see what I can do.
I believe the problem is how the sleep by closing the lid is handled. Right now both gnome-shell and gdm setup inhibitor locks, this is what I have on my system: :~ ▶ systemd-inhibit Who: Telepathy (UID 1000/maciek, PID 991/mission-control) What: shutdown:sleep Why: Disconnecting IM accounts before suspend/shutdown... Mode: delay Who: maciek (UID 1000/maciek, PID 876/gnome-settings-) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: gdm (UID 120/gdm, PID 709/gnome-settings-) What: handle-power-key:handle-suspend-key:handle-hibernate-key Why: GNOME handling keypresses Mode: block Who: gdm (UID 120/gdm, PID 709/gnome-settings-) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: GNOME Shell (UID 1000/maciek, PID 918/gnome-shell) What: sleep Why: GNOME needs to lock the screen Mode: delay Who: maciek (UID 1000/maciek, PID 876/gnome-settings-) What: handle-power-key:handle-suspend-key:handle-hibernate-key Why: GNOME handling keypresses Mode: block Who: NetworkManager (UID 0/root, PID 420/NetworkManager) What: sleep Why: NetworkManager needs to turn off networks Mode: delay Basically the keys are blocked, so systemd will not perform any action here. However sleep (triggered by lid close?) is set to delay (AFAIK this is controlled by logind.conf InhibitDelayMaxSec=, defaults to 5s). What happens here is that gnome-shell and gdm have only a finite amount of time to lock the desktop before systemd will put the system to sleep anyway [1]. So if any of these take action too late, there's a chance that the sleep will occur before the desktop is locked. Then upon wakeup, you'd briefly see the desktop in the pre-sleep state, promptly relaced by lock screen. I have not tried this yet (guess to lazy for editing config files, but not lazy enough to white this lengthy comment), but setting InhibitDelayMaxSec= to something like 30 should give g-s more than enough time to perform the locking. [1]. Perhaps someone from systemd would be able to confirm this.
(In reply to Maciek Borzecki from comment #30) > I believe the problem is how the sleep by closing the lid is handled. Right > now both gnome-shell and gdm setup inhibitor locks, this is what I have on > my system: > > :~ ▶ systemd-inhibit > Who: Telepathy (UID 1000/maciek, PID 991/mission-control) > What: shutdown:sleep > Why: Disconnecting IM accounts before suspend/shutdown... > Mode: delay > > Who: maciek (UID 1000/maciek, PID 876/gnome-settings-) > What: sleep > Why: GNOME needs to lock the screen > Mode: delay > > Who: gdm (UID 120/gdm, PID 709/gnome-settings-) > What: handle-power-key:handle-suspend-key:handle-hibernate-key > Why: GNOME handling keypresses > Mode: block > > Who: gdm (UID 120/gdm, PID 709/gnome-settings-) > What: sleep > Why: GNOME needs to lock the screen > Mode: delay > > Who: GNOME Shell (UID 1000/maciek, PID 918/gnome-shell) > What: sleep > Why: GNOME needs to lock the screen > Mode: delay > > Who: maciek (UID 1000/maciek, PID 876/gnome-settings-) > What: handle-power-key:handle-suspend-key:handle-hibernate-key > Why: GNOME handling keypresses > Mode: block > > Who: NetworkManager (UID 0/root, PID 420/NetworkManager) > What: sleep > Why: NetworkManager needs to turn off networks > Mode: delay > > Basically the keys are blocked, so systemd will not perform any action here. > However sleep (triggered by lid close?) is set to delay (AFAIK this is > controlled by logind.conf InhibitDelayMaxSec=, defaults to 5s). What happens > here is that gnome-shell and gdm have only a finite amount of time to lock > the desktop before systemd will put the system to sleep anyway [1]. So if > any of these take action too late, there's a chance that the sleep will > occur before the desktop is locked. Then upon wakeup, you'd briefly see the > desktop in the pre-sleep state, promptly relaced by lock screen. > > I have not tried this yet (guess to lazy for editing config files, but not > lazy enough to white this lengthy comment), but setting InhibitDelayMaxSec= > to something like 30 should give g-s more than enough time to perform the > locking. > > [1]. Perhaps someone from systemd would be able to confirm this. I just tried setting InhibitDelayMaxSec to 30s (the option was commented out) and tried suspending the laptop by closing the lid, but the issue still persists. If I lock my laptop before I close the lid, the lock screen is shown when I open the lid again, so I guess that reinforces your theory that Gnome doesn't get enough time to lock the screen.
I wasn't seeing this with F21, but I just upgraded to F22 and now it seems to happen every time. Gnome is definitely not getting time to lock the screen. In F21, I would see the lock screen come down, then the screen would go off. Now, the screen goes black instantly and when it resumes, then the lock happens.
I see that Gnome is trying to fade out because the screen that is visible on resume is dimmer than normal.
I have had this problem on several laptops but it has become an issue recently since I got a new laptop. I have been asked not to leave my laptop unattended at work unless it is turned off! They fear that people can see enough about a project I am working on from the screen. If I do not comply then I will be asked to only use Windows, they have the idea it is more secure and visibly it is! I have certainly had the problem from some time. I am sure I had the problem in F21 on my old acer laptop, but it was not as pronounced. The screen was only visible for a very short time plus the dimming noticed by Samuel Sieb was there. I don't think Gnome is trying to dim the screen because on my current set up it is brighter! I have dimmed the screen from the default and created a colour profile. Once I log on my personal settings come in and dim the screen.
Currently running Fedora 22 the lock screen does not activate until after returning from resume. The user's screen is visible, "unlocked" for 1-2 seconds. (it does seem like it went away, mostly, during F21, but it's definitely broken in F22) Richard (since you're assigned): it's not like you're not busy, but this is a security issue. Is there something we can do to help you get this sorted? AfC
I'm also experiencing this behavior on fully updated F22. It's 100% reproducible for me on a Lenovo T450 when sleeping/waking via cover close/open.
Me too. FC22, Sony Vaio pro 13. Screen is shown for a second on resume from suspend, whether via lid close or gnome menu suspend. pm-suspend doesn't activate the screensaver lock on resume, I'm just straight back where I left it. Please let me know if there's any hardware/driver info I can give to help diagnose this security issue.
This isn't gnome-settings-daemon's fault. It's a driver issue. Reassigning to gnome-shell, at the top of the driver stack.
seems like it's a driver issue related to dpms. Investigation is on-going, but see https://bugzilla.gnome.org/show_bug.cgi?id=753678 for more details.
FWIW, still happens with F23, ASUS N56VZ with Intel graphics. Happened also in F22 but not before that.
*** Bug 1282068 has been marked as a duplicate of this bug. ***
I confirm the issue persists on Fedora 23. Using the proposed workaround with InhibitDelayMaxSec=30 in /etc/systemd/logind.conf seems to fix the problem. Could we consider setting this as default in systemd package?
*** Bug 877513 has been marked as a duplicate of this bug. ***
Fixed for me now in FC23, thanks.
I have same symptoms with Cinnamon Desktop. Could that be caused by the same bug?
*** Bug 1272212 has been marked as a duplicate of this bug. ***
Moving to F23 per comment 40 and comment 42.
Please note that this may be an instance of CVE-2016-1000002 https://github.com/distributedweaknessfiling/DWF-Database-Artifacts/blob/master/DWF/2016/1000002/CVE-2016-1000002.json
FWIW, I do not see this behavior on fully updated F24.
Same here (both gdm and gnome-shell run with wayland backend). Haven't seen this in >2 months on F24.
I haven't seen it on F23 for a long time either.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am having this problem again today after upgrading to F25. Didn't have it with F24 or F23, had it previously w F22.
(In reply to Michael Bayer from comment #53) > I am having this problem again today after upgrading to F25. Didn't have it > with F24 or F23, had it previously w F22. Do you use X or Wayland? I still see it with F23.
Based on the method at http://unix.stackexchange.com/a/325972 I am using Wayland.
I am too experiencing this bug, but only on Wayland (Fedora 25) and not on X.
I'm not seeing this problem on F25 w/ Xwayland, though I've seen it off and on with F23 and F24. Xwayland is somewhere in between, right? Another data point in any case.
Just to confirm Paul DeStefano's observation. F23 and F24 both suffered when using X, the Wayland implementation on F25 does not. Although I guess this is irrelevant since the problem war almost certainly with X.
I'm seeing this with Fedora 25 and Wayland.
I also just had this happen with F25 and Wayland.
Me too F25 & Wayland
I am seeing this too - just upgraded to F25 on a DELL XPS 13 9350 - sometimes it works sometimes not - using Xwayland - I had this issue also on F23 Even worse sometimes it system does not wake up and resumes, but does a restart.
Hey, i also have this problem, but i also have a suggestion. It's more of a workaround than a proper fix, but couldn't you just render a black frame right before going to sleep, so that the frame that gets flashed is a black one instead of the user's desktop? I'm assuming that the bug is caused because the last frame before going to sleep gets displayed for a few miliseconds.
I've also been having this problem. I'm running F25 and Wayland. I didn't encounter this issue on F24, but it's occurred every time I've opened and closed my laptop on F25.
Just wanted to chime in that I'm also seeing this behavior. Fully updated Fedora 25 on an HP EliteBook Folio 9470m with Intel graphics. I'm using the default Wayland session, and this started as a fresh install of F25. Wake from suspend briefly flashes the contents of the screen prior to going to sleep. I found if I first lock the screen (Super+L), I don't see the screen contents before the lock screen is shown. This is because locking the screen prior to suspend blacks out the screen.
Also having this issue on F25 with Wayland. Haven't modified Gnome at all.
I didn't do any extensive testing, but it doesn't appear to happen when I use the Xorg session instead of Wayland. I prefer to forge ahead with Wayland, though.
Also having this issue; fully updated F25 Wayland. Consistently happens if I close the lid to sleep and then open. On Lenovo X270.
Still having this issue with F25. Waking the machine from lock/sleep briefly shows the desktop before the lock screen appears. How is such an embarrassing security oversight still present after 6+ years??
Zac no need to get upset, but in the meantime here's a workaround: if you press super+l (lock your pc) and then put your pc to sleep your desktop will no longer be flashed when waking up from sleep.
An initial test of this after upgrading to Fedora 26 suggests this issue is resolved. I encourage others who've commented here to upgrade to F26 at your earliest convenience and test again. I closed my lid with some windows open, waited for my laptop to go to sleep, and then opened back up to see only the lockscreen.
No, for me it definitely is not resolved with F26. When resuming from suspend the desktop is visible for about half a second and after hibernating it takes 3 seconds or more to show the lockscreen.
A couple of comments: If reporting success or failure, it helps to note whether this is with Wayland or X.org, and what your graphics hardware is, as these may influence things. While this bug refers to Gnome, I also have this issue with KDE and MATE on the same hardware (in my case, various generations of Intel integrated graphics), as the original reporter referenced. There's an upstream bug for the same issue with KDE, in which a developer notes "If you are on Intel make sure to use the xorg-modesettings driver!" (https://bugs.kde.org/show_bug.cgi?id=364915#c8). I understand Fedora 26 now uses the modesettings driver by default for all Intel graphics newer than gen 3 (http://hansdegoede.livejournal.com/16976.html), so perhaps that could have a positive effect -- under X.org, that is.
Good points, David. For me, I am still running a Wayland session on Ivy Bridge (third generation) Intel graphics.
Ok, so I just tried it on my laptop (intel Haswell graphics) and in Wayland sessions the issue is definitely still there, while in X sessions (both intel and modesetting driver) it works fine. On my pc (intel Ivy bridge and amd card, tried nearly every possible combination) I also saw the issue once or twice (always while running Wayland sessions), but I couldn't get consistent results because my monitor takes too long to wake up.
For what it's worth, the issue still occurs for me on F26 with GNOME3+Wayland on Intel Skylake HD Graphics 520 (Core i5-6200U) on a laptop, but not on my desktop Radeon 7770 (RadeonSI) connected through HDMI, possibly because the Radeon is slower to react or because the external monitor is slower to react than a laptop's built-in screen. While this issue is typically visible to those running a full Wayland-based GNOME Shell session these days, this used to happen for years when running under X. I believe the reason we tend to see it more easily on the Wayland session nowadays is just sheer luck, and that this is some sort of race condition that happens to currently manifest itself more easily with Wayland.
I'm also getting this and have done for years with both X and Wayland on a number of different systems. It's very reproducible for me. Mainly comenting to add a video of it in action: https://www.youtube.com/watch?v=qqT33qBpB4U
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still happening every time with F26/Wayland.
(In reply to Dimitris from comment #79) > Still happening every time with F26/Wayland. I bumped this to rawhide. Please let me know if you can reproduce there.
I just wanted to say I'm getting this on F27 / Wayland / nVidia 1080Ti, even when manually invoking using Command + L This is making Fedora hard to use in a professional environment - anyone who moves my mouse can see my emails or IMs unless I happen to remember to close them or quit slack etc.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This bug is also appearing on Ubuntu 17.10 with Gnome 3, using Xorg and lightDM for login screen etc... I think it is likely that this is not a Fedora/Redhat bug, but a Gnome bug - Has anyone opened a bug with Gnome?
(In reply to Kevin Walker from comment #83) > This bug is also appearing on Ubuntu 17.10 with Gnome 3, using Xorg and > lightDM for login screen etc... > > > I think it is likely that this is not a Fedora/Redhat bug, but a Gnome bug - > Has anyone opened a bug with Gnome? There is a linked upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=753678 It is possible there are multiple different bugs causing the same phenomenon in the end, though.
I am seeing this bug once again after upgrading from Fedora 26 to Fedora 27 about three weeks ago. I had the symptoms of this bug in Fedora 19 but they went away when I upgraded to Fedora 21 (in January 2015), and the problem has not returned until now. Currently on: Kernel: 4.16.7-200.fc27.x86_64 Gnome: Version 3.26.2
Me too. This reappeared in fc27.
This behavior reared its head again just now, fully updated F28 running X.
According to comment 49, I haven't seen this since F24.
See also https://bugzilla.gnome.org/show_bug.cgi?id=753678#c54. (There is further discussion in that Gnome bug -- already linked to this ticket -- that's relevant here.)
F29 here, same thing happens. Entire desktop flashes when waking up. XFCE has an option called "lock screen before sleep" which prevents that kind of crap. Can we get a secure lockscreen in Gnome3?
(In reply to lukasas from comment #90) > XFCE has an option called "lock screen before sleep" which prevents that kind of > crap. Hmm, it has that option, yes, but it does not (always) work. I have that option set in Xfce, but I also see the desktop flash before the screensaver shows up when I resume from suspend, often. It is not all the time, but most of the time. I haven't determined the pattern, but I think it has to do with whether I manually initiate the sleep or if the system does it to itself after inactivity. In the latter case, I can assume screensaver was running prior to sleep, though, so that option may not even be tested in that case. I cannot manually initiate suspend while xscreensaver is active. Although, I could be wrong and it is random. That's why I'm lurking here; once GNOME figures it out, I'll bug the Xfce team. Besides, I think this bug is for the former case, where one manually initiates suspend. The Xfce option is in the power settings, which may not even apply to this situation; it may only apply to power manager initiated sleep. I'm on rawhide/F30.
(In reply to Paul DeStefano from comment #91) > (In reply to lukasas from comment #90) > > XFCE has an option called "lock screen before sleep" which prevents that kind of > > crap. > > Hmm, it has that option, yes, but it does not (always) work. I have that > option set in Xfce, but I also see the desktop flash before the screensaver > shows up when I resume from suspend, often. It is not all the time, but > most of the time. Yep I have that option enabled in xfce and it has no effect on this bug. Desktop *always* shows on resume after manually suspending (e.g. pressing power button). This bug thread is almost 8 years old. Amazing.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I still see this occasionally on F29.
Still see it often on F30/xfce
hello from the future ! Just upgraded to F34 and suddenly this very old issue has popped up for me again, different laptop than the one I had in 2016. Anyone else ?
I have not seen this issue in years (using the most recent officially released Fedora), but this may also be related to the fact that my monitor immediately turns black when suspending my PC and it takes quite long to wake up before it displays anything.