1689929 - Download notification arrow animation flashes randomly, without an actual download having occurred

Status: NEW

(WebExtensions :: Frontend, enhancement, P5)

Description

[pablojvarela]

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

Steps to reproduce:

1. Open firefox.
2. Browse web.
3. Download file.
4. See download progress.
5. See download notification arrow flash when download completes.
6. Click download notification arrow for pop-up to show recent download.
7. Click "Show all downloads" and see list of downloaded files.
8. Continue browsing the internets.

Actual results:

The download notification arrow flashes as if a download activity had completed.
It happens randomly. More than once every now and then.
There was no download in progress.
Pop-up upon clicking the arrow does not show new downloads.
Clicking "Show all downloads" does not show new downloads.

Expected results:

The download notification arrow not flashing when there is no download activity completing.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Marco Bonardo [:mak]]

Could you please attach a log from about:support? I'd like to understand if you have any add-ons that may be interacting with the downloads API.

Comment 3

[pablojvarela]

Attachment: about-support.txt

Comment 4

[:Gijs (he/him)]

It doesn't seem super plausible any of your add-ons is implicated here -- but we don't see this so it's not clear what is causing it. It would be useful to doublecheck if disabling "simple tab groups" helps or not - there appears to be some downloads API use in that add-on.

Could you try setting browser.download.loglevel to "all" in about:config, and post the contents of the browser console (ctrl-shift-j; not the regular devtools console) when the problem occurs?

Comment 5

[Song Kim]

I'm having the same issue (Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0) and this is what I got from the browser console:

Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Attempting to notify that a new download has started or finished. DownloadsCommon.jsm:1076
Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Closing the downloads panel. downloads.js:239
Downloads: Downloads panel is not showing - nothing to do. downloads.js:242

Comment 6

[:Gijs (he/him)]

(In reply to Song Kim from comment #5)

I'm having the same issue (Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0) and this is what I got from the browser console:

Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Attempting to notify that a new download has started or finished. DownloadsCommon.jsm:1076
Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Closing the downloads panel. downloads.js:239
Downloads: Downloads panel is not showing - nothing to do. downloads.js:242

Right, so this does suggest that something is actually creating a download in the background... Unfortunately there are no stacks, so we don't know what is doing that. Can you reproduce in a clean profile? If not, is there any chance you can narrow down which add-on in your main profile is tripping this problem?

Comment 7

[Song Kim]

(In reply to :Gijs (he/him) from comment #6)

(In reply to Song Kim from comment #5)

I'm having the same issue (Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0) and this is what I got from the browser console:

Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Attempting to notify that a new download has started or finished. DownloadsCommon.jsm:1076
Downloads: Showing new download notification. DownloadsCommon.jsm:1092
Downloads: Closing the downloads panel. downloads.js:239
Downloads: Downloads panel is not showing - nothing to do. downloads.js:242

Right, so this does suggest that something is actually creating a download in the background... Unfortunately there are no stacks, so we don't know what is doing that. Can you reproduce in a clean profile? If not, is there any chance you can narrow down which add-on in your main profile is tripping this problem?

I don't think it is happening in a clean profile, though the bug shows up so sporadically I could have just missed it. I think turning off the Simple Tab Groups extension has stopped the arrow from showing up, but again I may have just missed it. It looks like pablojvarela also has that extension.

Comment 8

[:Gijs (he/him)]

:rpl, is there some way we can improve the add-on API so this doesn't happen?

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to :Gijs (he/him) from comment #8)

:rpl, is there some way we can improve the add-on API so this doesn't happen?

I guess that the STG addons is using the downloads API to automatically create periodic backups of its internal config, and that is currently the only option that an extension does have to store data as a file (and store it outside of the various storage APIs available to the extension, which are all cleared automatically when the extension is uninstalled), I'm pretty sure that STG isn't going to be the only extension being using this approach.

The json file that STG dumps is likely going to be pretty small and so the download will be completed pretty quickly (but it would stay visible in the Firefox downloads list).
I haven't looked the STG code, but I'm pretty sure that the STG extension may be listening for the the event fired when the download is completed and then calling downloads.erase to remove the download item from the list.

I'm actually surprised that we aren't requiring explicit user interaction for the downloads.erase method (instead we do require it for downloads.open), I'm wondering if that is also the case on Chrome.

I guess that if the download wouldn't be removed from the list, the behavior may become a bit less surprising to the users (the filename that STG does use is likely going to already suggest to the user what did trigger the download, but it may be a good thing if in the Firefox downloads list the downloads triggered by an extension would be more visibly associated to the addon that started the download).

I'll discuss about this with the rest of the team in our next triage meeting.

As a note to self:
I think that we will have to be careful about changing the behavior of the downloads API for at least a couple of reasons

• the API is shared with chrome and so we'll need to double-check the chrome-compatibility side effect of changing the behaviors in Firefox
• the extension may be currently making the assumptions that the current behaviors does always work, and so we'll need to double-check the side effects that the new behavior that we will agree on may have in terms of backward compatibility (and if it is going to be potentially backward incompatible, communicate the upcoming change up front and give the developers enough time to adjust their extensions)

Comment 10

[Shane Caraveo (:mixedpuppy)]

We could add some flag to the download api that indicates this type of use case is happening and we could avoid any ui interaction. But it's not important enough for us to focus on this.

Comment 11

[pablojvarela]

Sorry I missed out the conversation.
You all have been very helpfull.
I can confirm on the STG extension behavior as described by Luca Greco.

21:34:21.065 Downloads: Adding a new DownloadsViewItem to the downloads list. aNewest = true downloads.js:776
21:34:21.066 Downloads: The downloads item count has changed - we are tracking 2 downloads in total. downloads.js:633
21:34:21.066 Downloads: Setting the panel's hasdownloads attribute to true. downloads.js:642
21:34:21.066 Downloads: Attempting to notify that a new download has started or finished. DownloadsCommon.jsm:932
21:34:21.066 Downloads: Showing new download notification. DownloadsCommon.jsm:959
21:34:21.083 Downloads: Attempting to notify that a new download has started or finished. DownloadsCommon.jsm:932
21:34:21.083 Downloads: Showing new download notification. DownloadsCommon.jsm:959
21:34:21.084 Downloads: _updateStateInner, target exists?  /home/pablo/Downloads/STG-backups-FF-91.0.2/[e-mail] true DownloadsViewUI.jsm:594
21:34:21.278 Downloads: A download data item was removed. downloads.js:744
21:34:21.278 Downloads: Removing a DownloadsViewItem from the downloads list. downloads.js:803
21:34:21.279 Downloads: The downloads item count has changed - we are tracking 1 downloads in total. downloads.js:633
21:34:21.280 Downloads: Setting the panel's hasdownloads attribute to true.

I will keep an eye on the STG extension for any other strange behavior.
Thanks again for your time!!

Comment 12

[Albert Scheiner [:alberts]]

Having the same thing happening for ages. STG installed. Now, with the latest (great) updates to the download panel, the panel actually stays open after it gets "randomly" triggered.

Comment 13

[Shane Hughes [:aminomancer]]

If the plan described here pans out, we can add a brief delay (on "uninteractive" download start) to check that the download still exists before calling any of the indicator methods that play animation or set the attention state.