Open Bug 1719213 Opened 4 years ago Updated 2 years ago

Downloads get suspended when screen is locked

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 89
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: wruck, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Name Firefox
Version 89.0.2
Build-ID 20210622155641
Distributions-ID canonical
User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

OS is Xubuntu (Xfce) 20.04.2 LTS with light-locker to lock the screen.
Blank Firefox profile.

This used to work and broke in a recent update - might have been Firefox 88 but I'm not sure. Might also be some other part of the system.

To reproduce:

  • Start downloading a large file.
  • Lock the screen by either pressing Ctrl+Alt+L or waiting for the lock timeout to expire.
  • The system itself does not suspend, just the screen is locked and the display goes to sleep mode as expected.

Actual results:

When the screen gets locked, Firefox stops writing data to the .part file.
When the screen gets unlocked again (minutes or hours later) some more bytes get written to the file, in my tests the amount ranged from ~320 KB to ~5 MB.
If the screen had only been locked for a few seconds, the download continues. Most likely though, the connection has long been dropped by the server and the download fails.

Expected results:

Firefox should not stop writing data to disk when the screen gets locked.

My assumption is that Firefox continues the download, filling some internal buffer. When that is full, the download stalls until I unlock the screen and the buffer gets flushed. I'm not sure why this might be the case.
These are the corresponding DBus events:

signal time=1625315984.601286 sender=:1.10 -> destination=(null destination) serial=5008 path=/org/freedesktop/login1/session/c2; interface=org.freedesktop.login1.Session; member=Lock

signal time=1625317811.909852 sender=:1.10 -> destination=(null destination) serial=5014 path=/org/freedesktop/login1/session/c2; interface=org.freedesktop.login1.Session; member=Unlock

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Changing severity to S3 because workaround exists.

Severity: -- → S3
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

Turning on logging in about:networking confirms the assumption:

  • A short time after locking the screen, nsHttpConnection::OnSocketReadable can't write more segments to nsHttpTransaction, error code is NS_BASE_STREAM_WOULD_BLOCK
  • nsHttpTransaction::WriteSegments returns this error because writing to the nsPipe would block
    Turning on logging for nsPipe shows:
  • nsPipe::WriteSegments blocks because the pipe is full
  • When the screen locks, calls to nsPipe::ReadSegments from a BackgroundThread cease. Thus no more data is read from the pipe.
    Turning on logging for BackgroundFileSaver shows:
  • A BackgroundFileSaver is created for the download and destroyed on completion or failure.
    Turning on logging for events shows:
  • While the screen is locked, no events get delivered to the BackgroundThreadPool.

Since BackgroundFileSaver uses a BackgroundTaskQueue to write data out to disk, my current assumption is that this is driven by a continuous stream of events to the BackgroundThreadPool. This mechanism is suspended on Gtk/X11 when the screen gets locked.
I didn't find the code that causes this yet.

You need to log in before you can comment on or make changes to this bug.