Bugzilla

We have found the root cause of the issue. The issue is that Android requires notification updates to be 1 second apart. In our code [here](https://searchfox.org/mozilla-central/source/mobile/android/android-components/components/feature/downloads/src/main/java/mozilla/components/feature/downloads/AbstractFetchDownloadService.kt#347), 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.

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](https://searchfox.org/mozilla-central/source/mobile/android/android-components/components/feature/downloads/src/main/java/mozilla/components/feature/downloads/AbstractFetchDownloadService.kt#347), 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.