1812789 - Tapping on the Pause button on a downloading file and nothing happens

Status: NEW

(Firefox for Android :: Downloads, defect, P3)

Description

[Jeff Boek [:boek]]

From github: https://github.com/mozilla-mobile/fenix/issues/23933.

Steps to reproduce

1. Start 3 or more downloads.
2. Watch the progress by pulling down the drawer.
3. One file seems to stop downloading so you click on the Pause link on the one that has "stopped" and nothing happens.

Expected behaviour

When you click on the link Pause the download should be paused.

Actual behaviour

Nothing happens when you tap on the linked word Pause, but the linked word Cancel on the right aborts the download.

Device name

Samsung Galaxy S10+ (SM-G975F)

Android version

Android 12 (Lineage 19.0)

Firefox release type

Firefox Nightly

Firefox version

99.0a1

Device logs

No response

Additional information

No response

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Olivia Hall [:olivia]]

This is now occurring on Lineage OS.

Comment 2

[Nicholas Poon [:Nick]]

I tried reproducing this bug and got some unexpected behaviour that I believe may be related to this bug (and the bugs attached in the references section):

Steps to Reproduce

1. Download the same file at least 2 times. I did it 3 times. You can use this site: http://xcal1.vodafone.co.uk/
2. Let one of the downloads finish to completion and pause the remaining ones.
3. Check the downloads folder to see that there is 1 copy of the downloaded file.
4. Cancel one of the other paused downloads and notice that the downloaded file in downloads is now gone. Note that there were instances where I had to hit cancel on all of the remaining paused downloads for this unexpected behaviour to be observed.

Expected Behaviour

The downloaded file is still in the downloads folder untouched.

Actual Behaviour

The downloaded file is deleted from the downloads folder. Please see the attached video for more details.

Device Name

Samsung A35

Android Version

Android 14

Comment 3

[Nicholas Poon [:Nick]]

Notes after pairing with Titouan

• Due to the side effect mentioned in Comment 2, we noticed that the name of all 3 downloaded files remain the same during the download process. Usually, when more than 1 file is the same name, apps would add a (1), (2), (3), etc.... to the end of the file name. This suggested that perhaps the 3 downloads were being linked to the same file as Android was unable to tell the difference between the 3 files. Using this as inspiration, I tried to generate a random string as the file name and was no longer able to reproduce the above side effect, which is good news. However, I was still able to reproduce this bug. However, this is still an issue so one fix that needs to be done is to check whether the filename already exists in the download directory and renaming the file accordingly if so, as done here. It is also a possibility that bug 1825477 and bug 1812788 would be fixed with this fix. However, I am unable to verify this as I was unable to reproduce either bug.
• In terms of this bug, after some help from Jonathan, we were pointed in the direction that maybe the downloadJobs variable here was not being accessed / updated correctly. Since many coroutines exist, we believe that the calls to access / update this variable should only take place when a process holds a lock, which is currently not being done. More investigation still needs to be done with this idea in mind.

Comment 4

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

We have found the root cause of the issue. The issue is that Android requires notification updates to be 1 second apart. This all makes sense if we think about why download progress bars always update in chunks. In our code here, we can see that if 2 notifications are sent within a 1 second interval, we just skip the iteration of the for loop and don't update the notification.

We have 2 potential solutions here. Looking at how chrome implements their downloads, once you try to pause a download, chrome actually dismisses the notification tray immediately after the update. I think it is safe to assume that the reason they do this is because they don't want the user to be able to pause / interact with multiple chrome downloads / notifications within a 1 second interval, so they try to prevent this by automatically closing the notification tray in hopes that by the time the user reopens the notification tray that 1 second would have already passed.

The other solution would be to keep what we currently have (and not close the notification tray after every interaction with a download notification). Instead of just using a simple for loop, we would maintain a queue that would house the unprocessed notification updates and we would iterate through the queue instead of simply continuing and skipping over the notification update.

The advantage of the second approach is that users would be able to continue interacting with their other notifications after changing download status. However, there is currently a slight delay after clicking "Pause" or "Resume" on a download notification. On chrome, it is not noticeable because they immediately dismiss the notification tray after the update. If we follow through with our current approach, the delay will still be noticeable.

Comment 5

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

Attachment: Video of the Bug

Comment 6

[Nicholas Poon (redirect NI to [e-mail]) [:Nick]]

Attachment: Chrome's Implementation