Firefox seems to need “catchup time” after unlocking screen (using light-locker/lightdm)

(Possibly related to https://unix.stackexchange.com/questions/485591/after-unlocking-light-locker-screen-remains-blank-proportional-to-how-long-its) I’ve recently switched from xscreensaver to light-locker because of an annoying bug that hit me during the upgrade to xscreensaver 6.00). Am very happy with the switch except for the following issue: when I unlock back into my session, it appears that browsers were somehow suspended or maybe just lost network, because: * Electron apps show that they are reconnecting (Not really an issue) * Firefox appears to be doing CPU intensive work for ~2 minutes (for an overnight lock) and is unusable during that time frame. I assume it’s catching up with everything it missed? The 2 minutes of inoperative Firefox are a real hassle. Things that narrow it down: * This is on a desktop box that has continuous network access. (Not a laptop that loses wifi when lid closed etc.) * I’ve observed that other apps (launched from the command line prior to locking) have network access while the session is locked. (They continue serving data). * I’ve sshed into the box during lock and using ps/top, I’ve determined that firefox wasn’t “kill -STOPed” So my best guess is that something tells browsers to discontinue their use of network while the session is locked. Any idea what that might be? Maybe something systemd related? It doesn’t sound like such a terrible idea to suspend browsers while session is locked, but then is there any way to understand what Firefox is doing during these 2 minutes? (Trying to go to about:performance doesn't do anything because Firefox is just too busy to even answer that). **Update (10 Oct 2021):** It looks like light-locker invokes loginctl lock-session ... and I think that's what's driving the behavior of the browsers. This answer by @user1686 suggests that loginctl sends a "lock" signal to all the apps and so I guess what I need to do now is find out how Firefox responds to this and why it hangs as a result. **Major Update (16 Oct 2021):** With some strace-ing and experimentation, I've narrowed this down further to an unlikely place: hardware acceleration! During its minutes long busyloop, Firefox was of course making lots of syscall, but these really caught my attention:

[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_BUSY, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_MADVISE, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_PWRITE, 0x7f16e5c96260) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_BUSY, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_MADVISE, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_PWRITE, 0x7f16e5c96260) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_BUSY, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_MADVISE, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_PWRITE, 0x7f16e5c96260) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_BUSY, 0x7f16e5c96220) = 0
[pid 165855] 13:07:06 ioctl(35, DRM_IOCTL_I915_GEM_MADVISE, 0x7f16e5c96220) = 0

(Repeated many times, not exactly in the above pattern) First, I disabled the "Widevine Content Decryption Module provided by Google Inc." plugin. That didn't help. Then I tried disabling "Use hardware acceleration when available" in Performance → Settings and that did the trick: the next day Firefox was available immediately after I unlocked!!! While my immediate problem is solved, it still leaves me with a lot of questions: * This hardware acceleration box seems like a fairly coarse & opaque toggle that controls way more than I though (DRM?!?). What exactly does it do? * I still don't know how loginctl communicates with the browsers. A D-bus message? * How are the two linked? Is there a way to get some internal log that would be easier to make sense of than strace output? **Minor update (17 Oct 2021):** Unticking Digital Rights Management (DRM) Content → Play DRM-controlled content doesn't fix the issue (i.e. I can't turn hardware accelaration back on) **Minor update (18 Oct 2021):** Ticking Performance → Use recommended performance settings doesn't do the right thing either. I guess I'm ready to file that bug report now.