1741076 - [Linux] Downloads panel above other windows

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P3)

Description

[CarlosT]

Attachment: Download list above other window.png

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

Steps to reproduce:

Open firefox and maximize it.
Open other program, for example a terminal window and return to firefox.
Download something, and return to terminal.

Actual results:

Download panel shows above terminal. If terminal was maximized, download panel shows and then it dissapears.

Expected results:

Download panel should not be opened by default.

Comment 1

[CarlosT]

Nightly version: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0 ID:20211114093049
xUbuntu version: Ubuntu 18.04.5 LTS
XFCE version: 4.12

Comment 2

[Micah [:mtigley] (she/her)]

Are you able to see the issue when browser.download.improvements_to_download_panel preference is set to false? I suspect the panel opening more frequently due to this pref is highlighting a bug that's already been around. I'll see if I can reproduce the issue on a Linux VM

Comment 3

[CarlosT]

No. If that preference is set to false, i am not able to reproduce it. In fact, the panel does not open when i download something.

Comment 4

[Micah [:mtigley] (she/her)]

I was able to reproduce this on Ubuntu 20.04 LTS. Digging into this more, it looks like the issue with the panel overlapping other windows on Linux has been around for a while: Bug 1439609.

The browser.download.improvements_to_download_panel preference made this issue more apparent since it now opens the panel when there are no other downloads in progress. I believe we added an option to turn this off in Bug 1738372. You can go to about:preferences and set browser.download.alwaysOpenPanel to false, which would bring back the old behaviour of the panel.

I'm going to mark this as resolved since we have the browser.download.alwaysOpenPanel preference in place now, but feel free to re-open if you're still seeing the same issue.

Comment 5

[Anca Soncutean, Desktop QA]

Although the steps are straightforward I am not able to reproduce this issue on my Ubuntu 20.04 using Nightly 96.0a1 (buildID 20211114093049).

CarlosT can you help us with a confirmation of the fix on the latest beta build (download link). Thank you!

Comment 6

[CarlosT]

I downloaded the firefox-96.0b4 beta build, and, if i do not change any preference, i can't reproduce the bug (in fact, the panel does not open when i download something).

However, if i set browser.download.improvements_to_download_panel to true, the bug is still there.

Comment 7

[Anca Soncutean, Desktop QA]

Should this issue be reopened based on CarlosT’s previous comment: “if I set browser.download.improvements_to_download_panel to true, the bug is still there.” (although the mentioned pref is not default on true for now in beta, but it is in nightly)?

Comment 8

[Micah [:mtigley] (she/her)]

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #7)

Should this issue be reopened based on CarlosT’s previous comment: “if I set browser.download.improvements_to_download_panel to true, the bug is still there.” (although the mentioned pref is not default on true for now in beta, but it is in nightly)?

So I think there's two issues here:

1. The download panel opens much more frequently when the browser.download.improvements_to_download_panel is true. This happens when there are no other downloads in progress and another pref browser.download.alwaysOpenPanel is also true. By setting the latter to false, the panel will not open if it hasn't already.

2. The downloads panel always being on top another window seems to already be an issue on release. I've reproduced this on Firefox 94.0 on ubuntu. The introduction of the browser.download.improvements_to_download_panel made this more obvious (which we should file a separate ticket for anyway or reopen this issue focusing on that).

For now, you should be able to set browser.download.alwaysOpenPanel to false from about:config.

Comment 9

[Micah [:mtigley] (she/her)]

Re-opening this issue since the downloads panel is opened on top of other windows, which seems to be something that pre-dates the browser.download.improvements_to_download_panel pref.

Comment 10

[:Gijs (out until Jan 5th; he/him)]

Neil, I'm guessing this is a result of ui.panel.default_level_parent being true on linux and therefore the default popup level being top here. Can we "just" use level="parent" or something on the popup or override it some other way? The two problems at https://searchfox.org/mozilla-central/rev/7fa8371641ad33ce39f36a3bbd589b85ca2c9e45/modules/libpref/init/all.js#4210 don't sound too bad for the downloads popup as we want to move focus - right? (Maybe we'd need to manually move focus back to the main window on Linux when the panel closes?) Or is there some other way to address this?

Comment 11

[Neil Deakin]

I wouldn't think that the panel should open at all if its window is not active.

Comment 12

[:Gijs (out until Jan 5th; he/him)]

Attachment: Bug 1741076 - do not open the download panel if the window is not active, r?NeilDeakin

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/307260bd7469
do not open the download panel if the window is not active, r=NeilDeakin

Comment 14

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/307260bd7469

Comment 15

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

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 16

[:Gijs (out until Jan 5th; he/him)]

Comment on attachment 9258678 [details]
Bug 1741076 - do not open the download panel if the window is not active, r?NeilDeakin

Beta/Release Uplift Approval Request

• User impact if declined: Confusing download panel behaviour
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: use a site that triggers a download in the background (after some time; you can use gdocs' export function which usually takes a little while to actually generate stuff), and switch to a different window/app before the download starts. The downloads panel should not appear.
• List of other uplifts needed: bug 1731710
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple additional check that only affects whether/when we automatically show the panel
• String changes made/needed: N/A

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9258678 [details]
Bug 1741076 - do not open the download panel if the window is not active, r?NeilDeakin

Approved for 97.0b9.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/61fcf986c613

Comment 19

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox Nightly 98.0a1 (2022-01-26) on Ubuntu 20.04 x64.

Comment 20

[Hani Yacoub, Desktop QA]

After further investigations we observed that using a fresh profile for the first download the issue is still reproducible and the download panel is overlapping other windows, yesterday when we tested this we didn't use a new profile.
Is this behaviour expected for the first download or we should log a new bug for this?
Thanks.

Comment 21

[:Gijs (out until Jan 5th; he/him)]

(In reply to Hani Yacoub from comment #20)

After further investigations we observed that using a fresh profile for the first download the issue is still reproducible and the download panel is overlapping other windows, yesterday when we tested this we didn't use a new profile.
Is this behaviour expected for the first download or we should log a new bug for this?
Thanks.

It's not expected, please file a separate bug.

Comment 22

[Hani Yacoub, Desktop QA]

Logged Bug 1752349. We will continue verifying on this bug the scenario that doesn't include first download.

Comment 23

[Simona Badau, Desktop QA]

Verified as fixed using Firefox 97 beta 9 - the downloads panel is not displayed over other windows anymore. Tested on Ubuntu 20.04 x64 on a profile where the downloads panel was triggered before.

Comment 24

[Amir Yalchi]

I think this has caused bug 1782205.