GNOME Bugzilla – Bug 703430
screen recording robustness: suspend/resume
Last modified: 2021-07-05 14:29:02 UTC
From a downstream bug: If screencasting is started with gnome-shell and computer gets suspended, following resume, screencasting icons still appears as continuing recording however the resulting webm video ends at the moment of going to sleep. Version-Release number of selected component (if applicable): gnome-shell-3.6.2-6.el7.x86_64 (with Lenovo T42o) How reproducible: Only sometimes, perhaps after gnome-shell running for longer period of time. No relevant information printed in session.log Steps to Reproduce: 1. <ctrl><alt><shift>R to start recording 2. Suspend 3. "Continue" recording for a while before using the shortcut to toggle it off Actual results: A resulting video ends with suspending, however the recording OSD appears after resuming until using the shortcut. If this situation appears, I can keep reproducing every time until a gnome-shell restart. Expected results: Recording actually continues after the resuming every time.
Created attachment 248208 [details] [review] recorder: Pause during suspend When the system gets suspended during recording pause the recording and continue on resume.
Review of attachment 248208 [details] [review]: Do we need all of this? We are locking the screen on suspend, and that should disable the recorder component.
(In reply to comment #2) > Review of attachment 248208 [details] [review]: > > Do we need all of this? > We are locking the screen on suspend, and that should disable the recorder > component. It does not disable it (stop an already running recording).
(In reply to comment #3) > (In reply to comment #2) > > Review of attachment 248208 [details] [review] [details]: > > > > Do we need all of this? > > We are locking the screen on suspend, and that should disable the recorder > > component. > > It does not disable it (stop an already running recording). And I am not sure it should either ... if anything it should pause and resume afterwards. The reason for disallowing it during the lockscreen was that an attacker could use it to fill the disk. But if it got started during the session ...
Review of attachment 248208 [details] [review]: Jakub just said we should just stop instead of pause on suspend unless it hibernates because battery is running low (in that case pause + resume makes sense).
I think the use case for pausing video using hibernation is not very relevant. The primary use case for pausing is to skip ahead when something uninteresting is happening such as compilation or rendering, rather than the user needing to take a break. If we ever need a pause it would have to be an explicit action. I think we could trigger a notification on resume to notify the recoring has stopped. Stopping seems a better behavior as it avoids an unintentional screen recording of your session after a longer period of suspend.
(In reply to Jakub Steiner from comment #6) > I think we could trigger a notification on resume to notify the recoring has > stopped. Stopping seems a better behavior as it avoids an unintentional > screen recording of your session after a longer period of suspend. Nowadays we actually stop the recording when the screen is locked, no matter whether we are about to suspend or not. I don't think a notification makes sense on screen lock, so should we let the recording continue and only stop it on suspend?
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.