Open Bug 1945935 Opened 8 days ago Updated 2 days ago

Slow download speeds up after cancel/retry

Categories

(Core :: Networking, defect, P3)

Firefox 134
defect

Tracking

()

UNCONFIRMED

People

(Reporter: rcharbon, Unassigned)

Details

(Whiteboard: [necko-triaged][necko-priotity-review])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

  1. Download a large file (for example, the full client installer for Windows at: https://www.teamviewer.com/en-us/download/windows/)
  2. Click on "Display progress of ongoing downloads" Notice download is very slow.
  3. Cancel download.
  4. Restart download from "Display progress" button. Download is now approx. 100x faster

Actual results:

See above, and see also profile at: https://share.firefox.dev/4gqKdEM

Expected results:

Download should be fast from the start, like it is in all other browsers tested.

The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Downloads Panel

Download speed is closer to Network than Downloads management, so moving to a more appropriate component.

Component: Downloads Panel → Networking
Product: Firefox → Core

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 136.0a1(2025-02-03) on Ubuntu 22.04
Could you please answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
  3. Do you have any addons installed? If yes could you please list them?
Flags: needinfo?(rcharbon)

(In reply to Negritas Sergiu, Desktop QA from comment #3)

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 136.0a1(2025-02-03) on Ubuntu 22.04

Wouldn't it be a good idea to try and reproduce a problem with the Windows client on Windows?

Flags: needinfo?(rcharbon)

(In reply to Negritas Sergiu, Desktop QA from comment #3)

Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 136.0a1(2025-02-03) on Ubuntu 22.04
Could you please answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
  2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
  3. Do you have any addons installed? If yes could you please list them?
  1. The issue is reproducible in a new profile.
  2. The issue is reproducible in v136.0b2
  3. ClearURLs, Ublock Orgin (not loaded in the test profile used in 1)
  1. The issue is reproducible on a second Windows 11 system.

I checked the profile and I dont notice any obvious errors.
The only difference between the two request is the priority (first request was highest (-20) and retry after cancel was normal (0)).

btw, I noticed sometimes we speed up after cancelling requests on my Mac as well, so dont think this is windows specific.

Kershaw, do you notice anything unusual here?

Flags: needinfo?(kershaw)
Whiteboard: [necko-triaged][necko-priotity-review]
Severity: -- → S3
Priority: -- → P3

I also can't reproduce this.

It'd be helpful if we can have a http log to debug this.
Reporter, could you try to capture a http log?
In about:logging, please select logging to file and send the file to necko@mozilla.com.

Thanks.

Flags: needinfo?(kershaw) → needinfo?(rcharbon)

It would be helpful to know what client you were using when unable to reproduce.

(In reply to Kershaw Chang [:kershaw] from comment #8)

I also can't reproduce this.

It'd be helpful if we can have a http log to debug this.
Reporter, could you try to capture a http log?
In about:logging, please select logging to file and send the file to necko@mozilla.com.

Thanks.

Flags: needinfo?(rcharbon) → needinfo?(kershaw)

Log file sent. There was a zero byte child log file which wasn't sent.
(In reply to Kershaw Chang [:kershaw] from comment #8)

I also can't reproduce this.

It'd be helpful if we can have a http log to debug this.
Reporter, could you try to capture a http log?
In about:logging, please select logging to file and send the file to necko@mozilla.com.

Thanks.

Flags: needinfo?(kershaw)

Thanks for the log.

This seems to related to HTTP/3.
To troubleshoot the slow download issue, could you open Firefox and go to about:config, search for network.http.http3.enable, set it to false, and then try downloading the file again to see if the speed improves. Additionally, test the download using other browsers that support HTTP/3 to see if the slowdown occurs elsewhere as well.

Flags: needinfo?(rcharbon)

As noted in the original report:
Expected results:
Download should be fast from the start, like it is in all other browsers tested.
Those browsers being Chrome and Edge

Disabling HTTP3 had no effect.

(In reply to Kershaw Chang [:kershaw] from comment #11)

Thanks for the log.

This seems to related to HTTP/3.
To troubleshoot the slow download issue, could you open Firefox and go to about:config, search for network.http.http3.enable, set it to false, and then try downloading the file again to see if the speed improves. Additionally, test the download using other browsers that support HTTP/3 to see if the slowdown occurs elsewhere as well.

Flags: needinfo?(rcharbon)
You need to log in before you can comment on or make changes to this bug.