Bugzilla

(In reply to :Gijs (he/him) from comment #4)
> The original point of this flag was for the "old" behaviour of showing the panel the first time (ever) there was a download in a given Firefox profile, to help users discover the downloads panel.

I think I misunderstood something from bug 766263. For some reason I thought this pref was supposed to reset on each session, and then was later changed to persist between sessions. But upon closer examination I guess this has always worked the same way. So I see what you mean that if the panel has never been shown, we should show it no matter what except in that very narrow, unusual circumstance of a download launched by an extension without user interaction.

But I'm not convinced that would be a separate bug. I think that flag is actually the sole cause of the behavior Catalin reported. I did some testing and it seems the behavior on Windows 10 is actually the same as Catalin reported for other OSes. When I first tested it on my own profile, the panel didn't open. But I tried it on a new profile and it did open the first time. Upon setting `browser.download.panel.shown` to false, it opened again. Catalin's description sounds similar.

(In reply to Catalin Sasca, QA [:csasca] from comment #5)
> The panel is opening only if initiating the first download on a clean profile. After that, it won't open anymore and only show the blue tick when the download is done exactly as in the attachment GIF.

Hey Catalin, from your description it sounds like the panel only opens once, on the first download of a clean profile. If you run this test again a couple times and confirm that the panel is not opening, can you then try setting `browser.download.panel.shown` to false in about:config, and try again? And you can try the same on Windows 10. I'm guessing you tested on Windows 10 but it wasn't a clean profile, so that pref was already set to true?

If that's right, then I think this is actually working exactly as expected. The panel is supposed to not open, but it does open for the first download of a profile, because of the way panelHasShownBefore is checked. If the top window is not active, but panelHasShownBefore is false, we're still going to open the panel. And then we set panelHasShownBefore to true, and then future downloads won't open the panel.

So I think we want to clean up that check a bit so that, if the window is not active or the download was launched by an extension without a user interaction, we skip opening the panel, in order to avoid the behavior where the downloads panel floats above other application windows. If it happens that the first download on a profile happens while the window is inactive, and we skip opening the panel, there will still be future opportunities to show the panel. We only set the flag to true if we actually open the panel. So instead of opening on the 1st download, it would just open on the 2nd download instead. Or whichever is the first download to happen while the window is active.

(In reply to :Gijs (he/him) from comment #4)
> The original point of this flag was for the "old" behaviour of showing the panel the first time (ever) there was a download in a given Firefox profile, to help users discover the downloads panel.

I think I misunderstood something from bug 766263. For some reason I thought this pref was supposed to reset on each session, and then was later changed to persist between sessions. But upon closer examination I guess this has always worked the same way. So I see what you mean that if the panel has never been shown, we should show it no matter what except in that very narrow, unusual circumstance of a download launched by an extension without user interaction.

But I'm not convinced that would be a separate bug. I think that flag is actually the sole cause of the behavior Catalin reported. I did some testing and it seems the behavior on Windows 10 is actually the same as Catalin reported for other OSes. When I first tested it on my own profile, the panel didn't open. But I tried it on a new profile and it did open the first time. Upon setting `browser.download.panel.shown` to false, it opened again. Catalin's description sounds similar.

(In reply to Catalin Sasca, QA [:csasca] from comment #5)
> The panel is opening only if initiating the first download on a clean profile. After that, it won't open anymore and only show the blue tick when the download is done exactly as in the attachment GIF.

Hey Catalin, from your description it sounds like the panel only opens once, on the first download of a clean profile. If you run this test again a couple times and confirm that the panel is not opening, can you then try setting `browser.download.panel.shown` to false in about:config, and try again? And you can try the same on Windows 10. I'm guessing you tested on Windows 10 but it wasn't a clean profile, so that pref was already set to true?

If that's right, then I think this is actually working exactly as expected. The panel is supposed to not open, but it does open for the first download of a profile, because of the way panelHasShownBefore is checked. If the top window is not active, but panelHasShownBefore is false, we're still going to open the panel. And then we set panelHasShownBefore to true, and then future downloads won't open the panel.

So I think we want to clean up that check a bit so that, if the window is not active or the download was launched by an extension without a user interaction, we skip opening the panel, in order to avoid the behavior where the downloads panel floats above other application windows. If it happens that the first download on a profile happens while the window is inactive, and we skip opening the panel, there will still be future opportunities to show the panel. We only set the flag to true if we actually open the panel. So instead of opening on the 1st download, it would just open on the 2nd download instead. Or whichever is the first download to happen while the window is active.

Edit: And actually, it turns out it's a lot harder to check specifically for the case where the download was started by an extension without user interaction, because we used the same flag for all the other cases as well. Right now, it's set up to skip showing the panel for _any_ of those cases where `openDownloadsListOnStart` is false — regardless of `panelHasShownBefore`. So that includes the extension without user input case, but it also includes the cases covered by the other 2 bugs. So to patch that, we could create a new property only set by the downloads API. And then we could check `if ((openDownloadsListOnStart && this.panelHasShownBefore) || !isHandlingUserInput) skip panel...`