1813365 - If the download button is not in place when the window opens, the download button will not display progress

Status: RESOLVED WORKSFORME

(Firefox :: Downloads Panel, defect, P3)

Description

[k08045kk]

Attachment: downlod-button.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

Steps to reproduce:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Firefox Nightly 111.0a1 (2023-10-28) (64-bit)

1. Remove the download button from the Firefox UI.
2. Restart the Firefox.
3. Place the download button from the Firefox UI.
4. Download large time-consuming file in Firefox.

• Example: Linux ISO file
  https://ubuntu.com/download/desktop
  (The download button can be placed/removed from the context menu [Customize Toolbar...] in the context menu)
  (This is different from [Hide Button When Empty] in the context menu)

Actual results:

After the file download starts, the circular progress is not displayed on the download button.
After the animation of the start of downloading, the icon of the down arrow of the un-downloaded state is displayed.
The left side of the attached image is an example of the NG pattern. The right side is the OK pattern.

Expected results:

Please display the progress even immediately after the download button is placed.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[Daniel Bodea [:danibodea]]

I can confirm this report on all the main channels (Nightly v111.0a1, Beta v110.0b7, Release v109.0 and vESR v102.0esr) on Windows 10 and Ubuntu 22.
When the user removes the button, then restarts and puts it back in the UI, the download button will not show the progress animation. After another restart, the animation will display again.

Comment 3

[Sam Foster [:sfoster] (he/him)]

We probably need to ensure the indicator's initializeIndicator method is called when the button get restored. Currently that only gets called during _delatedStartup by the window's browser.js.

I'm not sure this is good-first-bug material as we'd want a test to go with the fix, but it might be a good 2nd bug.

Comment 4

[rishat11.11k]

Env: Windows 11 pro, Firefox v. 109.0.1 (x64)
I confirm this bug. The loading animation does not change with the amount of file loaded.
You cannot "Pause" the download, only "Cancel" or "Retry download"

Comment 5

[Lata]

Hey! I am intrested in working on this bug. Can you assign me this? Also, Can you please guide me how to start with it?

Comment 6

[Carlos Duarte do Nascimento (Chester)]

Hello! Considering this as a first bug, so I tried the steps on macOS Sonoma 14.1, with regular Firefox (119.0) and Nightly (121.0a1), and both do show the circular animation after step 4.

Can't add images, so here is a GIF capture of the repro on Nightly: https://github-production-user-asset-6210df.s3.amazonaws.com/236297/280355540-fe110ba9-4128-48f3-aac7-1a289cb02f28.gif

Wonder whether this is exclusive to Windows/Linux, was fixed in a previous release or if my reproduction is wrong. Any advice?

Comment 7

[u741613]

Hi. I also considered to have a look into this. I tested it on Fedora Linux 39 (Workstation Edition) with Firefox 121.0 (64-bit) but I was not able to reproduce the bug. I did:

1. removed the download button
2. restarted firefox
3. open customize menu, drag button back onto the toolbar
4. initiate a download
   I could see the download button display progress.

I tried to reproduce it several times, also removing the button via context menu and drag & drop, but it looked to me like it worked.

Comment 8

[k08045kk]

I tested it on Windows 10 and Firefox 121.0.1, but the bug could not be reproduced.
I'm happy with this. thank you very much.

Comment 9

[Sam Foster [:sfoster] (he/him)]

Removing the good-first-bug tag for now as people are having trouble reproducing this.

:danibodea, are you still able to reproduce this?

Comment 10

[Daniel Bodea [:danibodea]]

While attempting to find a fix, I managed to reproduce it in Nightly v111.0a1 (2023-01-11) through to v112.0a1 (2023-02-14).

Mozregression results:
Tested mozilla-central build: 2023-02-14 (verdict: b)
Tested mozilla-central build: 2023-02-15 (verdict: g)

This bug stopped reproducing in later builds.

Comment 11

[Sam Foster [:sfoster] (he/him)]

Thanks for the confirmation. Looking at the commit history for that period, bug 1816725 looks like a possible candidate for the fix? Either way I can close this.