Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window.
Bug 1782205 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window. Edit: By the way, I think the panelHasShownBefore flag ought to be used a bit differently now that alwaysOpenPanel exists. The former long predates the latter so I think I understand why they might conflict. panelHasShownBefore was supposed to keep the panel closed after the user closed it. But at that time, it was the only check. Now there are a bunch. So right now, the way it's functioning is as an override to the _other_ checks that are supposed to suppress the panel under certain circumstances. With the exception of the new [openDownloadsListOnStart](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1024) flag, all the other checks that result in `!shouldOpenDownloadsPanel` (like `browserWin == Services.focus.activeWindow`) will be canceled out if this is the first download of the session. We're basically saying: ``` if (this.panelHasShownBefore && !shouldOpenDownloadsPanel) { show notification instead of panel... } ``` Which has the effect of guaranteeing that the downloads panel is shown on the first download created in a session, even if it was created by sources that definitely shouldn't show the panel. For example, the bug that initially prompted us to create this openDownloadsListOnStart flag was one that involved extensions downloading files without any user interaction as a storage method. Users were seeing the panel pop up for what appeared to be no reason, because as soon as the download was created, the extension cleared it out. So, downloads created under those circumstances (as basically a hacky method of extension storage) should never open the panel, even if the panel has not been shown before. But as the checks are currently set up, we're basically saying we can only replace the panel with an indicator animation if the panel has not been shown before. Both checks need to pass — the panel needs to have been suppressed by other checks (such as the extension user interaction check) AND the panel needs to have been previously opened. I think this just fell under the radar because the checks have become so numerous and confusing. What we should be doing instead is to basically change the AND operation to an OR. If the panel was previously opened, and alwaysOpenPanel is disabled, then don't open the panel. Otherwise, if any of our other checks failed, don't open the panel. I think this is about right: ``` let shouldOpenDownloadsPanel = openDownloadsListOnStart && aType == "start" && DownloadsCommon.summarizeDownloads(this._downloads).numDownloading <= 1 && browserWin == Services.focus.activeWindow; // Current behavior is for the downloads panel to always open except in the // circumstances checked above. However, the user can override this behavior by // disabling the alwaysOpenPanel pref or by disabling the downloads panel // improvements altogether. This will revert the panel to the traditional // behavior of opening the downloads panel automatically once per session. let alwaysOpen = lazy.gAlwaysOpenPanel && Services.prefs.getBoolPref("browser.download.improvements_to_download_panel"); // If we're not showing the panel, then provide a visible notification in the // topmost browser window. Also ensure that if openDownloadsListOnStart = false // is passed, we always skip opening the panel. That's because this will only be // passed if the download is started without user interaction, if a dialog was // previously opened in the process of the download (e.g. unknown content type // dialog), or if the download was created by certain context menu items. if ( aType != "error" && (!shouldOpenDownloadsPanel || !openDownloadsListOnStart || (this.panelHasShownBefore && !alwaysOpen)) ) { DownloadsCommon.log("Showing new download notification."); browserWin.DownloadsIndicatorView.showEventNotification(aType); return; } this.panelHasShownBefore = true; browserWin.DownloadsPanel.showPanel(); ```
Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window. --------------------- Edit: By the way, I think the panelHasShownBefore flag ought to be used a bit differently now that alwaysOpenPanel exists. The former long predates the latter so I think I understand why they might conflict. panelHasShownBefore was supposed to keep the panel closed after the user closed it. But at that time, it was the only check. Now there are a bunch. So right now, the way it's functioning is as an override to the _other_ checks that are supposed to suppress the panel under certain circumstances. With the exception of the new [openDownloadsListOnStart](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1024) flag, all the other checks that result in `!shouldOpenDownloadsPanel` (like `browserWin == Services.focus.activeWindow`) will be canceled out if this is the first download of the session. We're basically saying: ``` if (this.panelHasShownBefore && !shouldOpenDownloadsPanel) { show notification instead of panel... } ``` Which has the effect of guaranteeing that the downloads panel is shown on the first download created in a session, even if it was created by sources that definitely shouldn't show the panel. For example, the bug that initially prompted us to create this openDownloadsListOnStart flag was one that involved extensions downloading files without any user interaction as a storage method. Users were seeing the panel pop up for what appeared to be no reason, because as soon as the download was created, the extension cleared it out. So, downloads created under those circumstances (as basically a hacky method of extension storage) should never open the panel, even if the panel has not been shown before. But as the checks are currently set up, we're basically saying we can only replace the panel with an indicator animation if the panel has not been shown before. Both checks need to pass — the panel needs to have been suppressed by other checks (such as the extension user interaction check) AND the panel needs to have been previously opened. I think this just fell under the radar because the checks have become so numerous and confusing. What we should be doing instead is to basically change the AND operation to an OR. If the panel was previously opened, and alwaysOpenPanel is disabled, then don't open the panel. Otherwise, if any of our other checks failed, don't open the panel. I think this is about right: ``` let shouldOpenDownloadsPanel = openDownloadsListOnStart && aType == "start" && DownloadsCommon.summarizeDownloads(this._downloads).numDownloading <= 1 && browserWin == Services.focus.activeWindow; // Current behavior is for the downloads panel to always open except in the // circumstances checked above. However, the user can override this behavior by // disabling the alwaysOpenPanel pref or by disabling the downloads panel // improvements altogether. This will revert the panel to the traditional // behavior of opening the downloads panel automatically once per session. let alwaysOpen = lazy.gAlwaysOpenPanel && Services.prefs.getBoolPref("browser.download.improvements_to_download_panel"); // If we're not showing the panel, then provide a visible notification in the // topmost browser window. Also ensure that if openDownloadsListOnStart = false // is passed, we always skip opening the panel. That's because this will only be // passed if the download is started without user interaction, if a dialog was // previously opened in the process of the download (e.g. unknown content type // dialog), or if the download was created by certain context menu items. if ( aType != "error" && (!shouldOpenDownloadsPanel || !openDownloadsListOnStart || (this.panelHasShownBefore && !alwaysOpen)) ) { DownloadsCommon.log("Showing new download notification."); browserWin.DownloadsIndicatorView.showEventNotification(aType); return; } this.panelHasShownBefore = true; browserWin.DownloadsPanel.showPanel(); ```
Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window. --------------------- Edit: By the way, I think the panelHasShownBefore flag ought to be used a bit differently now that alwaysOpenPanel exists. The former long predates the latter so I think I understand why they might conflict. panelHasShownBefore was supposed to keep the panel closed after the user closed it. But at that time, it was the only check. Now there are a bunch. So right now, the way it's functioning is as an override to the _other_ checks that are supposed to suppress the panel under certain circumstances. With the exception of the new [openDownloadsListOnStart](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1024) flag, all the other checks that result in `!shouldOpenDownloadsPanel` (like `browserWin == Services.focus.activeWindow`) will be canceled out if this is the first download of the session. We're basically saying: ``` if (this.panelHasShownBefore && !shouldOpenDownloadsPanel) { show notification instead of panel... } ``` Which has the effect of guaranteeing that the downloads panel is shown on the first download created in a session, even if it was created by sources that definitely shouldn't show the panel. For example, the bug that initially prompted us to create this openDownloadsListOnStart flag was one that involved extensions downloading files without any user interaction as a storage method. Users were seeing the panel pop up for what appeared to be no reason, because as soon as the download was created, the extension cleared it out. So, downloads created under those circumstances (as basically a hacky method of extension storage) should never open the panel, even if the panel has not been shown before. But as the checks are currently set up, we're basically saying we can only replace the panel with an indicator animation if the panel has previously been shown by this method. Both checks need to pass — the panel needs to have been suppressed by other checks (such as the extension user interaction check) AND the panel needs to have previously been opened. I think this just fell under the radar because the checks have become so numerous and confusing. What we should be doing instead is to basically change the AND operation to an OR. If the panel was previously opened, and alwaysOpenPanel is disabled, then don't open the panel. Otherwise, if any of our other checks failed, don't open the panel. I think this is about right: ``` let shouldOpenDownloadsPanel = openDownloadsListOnStart && aType == "start" && DownloadsCommon.summarizeDownloads(this._downloads).numDownloading <= 1 && browserWin == Services.focus.activeWindow; // Current behavior is for the downloads panel to always open except in the // circumstances checked above. However, the user can override this behavior by // disabling the alwaysOpenPanel pref or by disabling the downloads panel // improvements altogether. This will revert the panel to the traditional // behavior of opening the downloads panel automatically once per session. let alwaysOpen = lazy.gAlwaysOpenPanel && Services.prefs.getBoolPref("browser.download.improvements_to_download_panel"); // If we're not showing the panel, then provide a visible notification in the // topmost browser window. Also ensure that if openDownloadsListOnStart = false // is passed, we always skip opening the panel. That's because this will only be // passed if the download is started without user interaction, if a dialog was // previously opened in the process of the download (e.g. unknown content type // dialog), or if the download was created by certain context menu items. if ( aType != "error" && (!shouldOpenDownloadsPanel || !openDownloadsListOnStart || (this.panelHasShownBefore && !alwaysOpen)) ) { DownloadsCommon.log("Showing new download notification."); browserWin.DownloadsIndicatorView.showEventNotification(aType); return; } this.panelHasShownBefore = true; browserWin.DownloadsPanel.showPanel(); ```
Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window. --------------------- Edit: By the way, I think the panelHasShownBefore flag ought to be used a bit differently now that alwaysOpenPanel exists. The former long predates the latter so I think I understand why they might conflict. panelHasShownBefore was supposed to keep the panel closed after the user closed it. But at that time, it was the only check. Now there are a bunch. So right now, the way it's functioning is as an override to the _other_ checks that are supposed to suppress the panel under certain circumstances. With the exception of the new [openDownloadsListOnStart](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1024) flag, all the other checks that result in `!shouldOpenDownloadsPanel` (like `browserWin == Services.focus.activeWindow`) will be canceled out if this is the first download of the session. We're basically saying: ``` if (this.panelHasShownBefore && !shouldOpenDownloadsPanel) { show notification instead of panel... } ``` Which has the effect of guaranteeing that the downloads panel is shown on the first download created in a session, even if it was created by sources that definitely shouldn't show the panel. For example, the bug that initially prompted us to create this openDownloadsListOnStart flag was one that involved extensions downloading files without any user interaction as a storage method. Users were seeing the panel pop up for what appeared to be no reason, because as soon as the download was created, the extension cleared it out. So, downloads created under those circumstances (as basically a hacky method of extension storage) should never open the panel, even if the panel has not been shown before. But as the checks are currently set up, we're basically saying we can only replace the panel with an indicator animation if the panel has previously been shown by this method. Both checks need to pass — the panel needs to have been suppressed by other checks (such as the extension user interaction check) AND the panel needs to have previously been opened. I think this just fell under the radar because the checks have become so numerous and confusing. What we should be doing instead is to basically change the AND operation to an OR. If the panel was previously opened, and alwaysOpenPanel is disabled, then don't open the panel. Otherwise, if any of our other checks failed, don't open the panel. I think this is about right: ``` let shouldOpenDownloadsPanel = openDownloadsListOnStart && aType == "start" && DownloadsCommon.summarizeDownloads(this._downloads).numDownloading <= 1 && browserWin == Services.focus.activeWindow; // Current behavior is for the downloads panel to always open except in the // circumstances checked above. However, the user can override this behavior by // disabling the alwaysOpenPanel pref or by disabling the downloads panel // improvements altogether. This will revert the panel to the traditional // behavior of opening the downloads panel automatically once per session. let alwaysOpen = lazy.gAlwaysOpenPanel && Services.prefs.getBoolPref("browser.download.improvements_to_download_panel"); // If we're not showing the panel, then provide a visible notification in the // topmost browser window. Also ensure that if openDownloadsListOnStart = false // is passed, we always skip opening the panel. That's because this will only be // passed if the download is started without user interaction, if a dialog was // previously opened in the process of the download (e.g. unknown content type // dialog), or if the download was created by certain context menu items. if ( aType != "error" && (!shouldOpenDownloadsPanel || (this.panelHasShownBefore && !alwaysOpen)) ) { DownloadsCommon.log("Showing new download notification."); browserWin.DownloadsIndicatorView.showEventNotification(aType); return; } this.panelHasShownBefore = true; browserWin.DownloadsPanel.showPanel(); ```
Judging from the recording and the fact that it doesn't affect Windows 10, I suppose this is not expected behavior, but the code related to bug 1741076 is not at fault. The reason bug 1741076 triggered this issue is just that before it, the downloads panel always opened when a download started, regardless of whether the window was active. But now, the panel is not supposed to open when the window is inactive. The problem I'm seeing is that for some reason, the window is considered active the first time and not on subsequent drag-and-drops. So it should either never open in this context or always open in this context. But I suspect the reason that's inconsistent is a much lower-level issue, maybe with the drag service? What's happening in Windows 10? Is the panel always opening or is it never opening? Its showing the first time might be caused by [panelHasShownBefore](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1023,1030). If we want the downloads panel to always open when dragging and dropping into the window, then we could try to manually set that flag when the download is created by drag-and-drop. But there might be an independent reason for not wanting to open the downloads panel under these circumstances. Bug 1761265 prevents the panel from opening when the download was triggered by a user action that is expected to create a download. I don't know if this really counts, because the user action (drag-and-drop) is simpler and doesn't always create a download. But that would be worth considering, because I think that determines who is best positioned to work on this bug. If we want to ensure the downloads panel always opens on drag and drop, then I think the frontend team would want to add a new flag that [overrides this check](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1011), and have the drag-and-drop consumer that leads to download creation set that flag. Such a flag might be useful for other download sources that require some other application to be focused. If we _don't_ want the panel to ever open for downloads created by drag-and-drop, then we could just do the same thing in reverse I guess. But if we don't want to set a rule for this specific action, and just use the normal rules (check the alwaysOpenPanel pref, check window activity), then it seems the problem, at least on Windows, might be a widget/toolkit thing. I'm personally inclined toward seeing the downloads panel always open in the top window when a download is created by drag-and-drop, and I think it would be good to get a new flag since there might be some other download sources that come from another application and don't focus the Firefox window. --------------------- Edit: By the way, I think the panelHasShownBefore flag ought to be used a bit differently now that alwaysOpenPanel exists. The former long predates the latter so I think I understand why they might conflict. panelHasShownBefore was supposed to keep the panel closed after the user closed it. But at that time, it was the only check. Now there are a bunch. So right now, the way it's functioning is as an override to the _other_ checks that are supposed to suppress the panel under certain circumstances. With the exception of the new [openDownloadsListOnStart](https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/browser/components/downloads/DownloadsCommon.jsm#1024) flag, all the other checks that result in `!shouldOpenDownloadsPanel` (like `browserWin == Services.focus.activeWindow`) will be canceled out if this is the first download of the session. We're basically saying: ``` if (this.panelHasShownBefore && !shouldOpenDownloadsPanel) { show notification instead of panel... } ``` Which has the effect of guaranteeing that the downloads panel is shown on the first download created in a session, even if it was created by sources that definitely shouldn't show the panel. For example, the bug that initially prompted us to create this openDownloadsListOnStart flag was one that involved extensions downloading files without any user interaction as a storage method. Users were seeing the panel pop up for what appeared to be no reason, because as soon as the download was created, the extension cleared it out. So, downloads created under those circumstances (as basically a hacky method of extension storage) should never open the panel, even if the panel has not been shown before. But as the checks are currently set up, we're basically saying we can only replace the panel with an indicator animation if the panel has previously been shown by this method. Both checks need to pass — the panel needs to have been suppressed by other checks (such as the extension user interaction check) AND the panel needs to have previously been opened. I think this just fell under the radar because the checks have become so numerous and confusing. What we should be doing instead is to basically change the AND operation to an OR. If the panel was previously opened, and alwaysOpenPanel is disabled, then don't open the panel. Otherwise, if any of our other checks failed, don't open the panel. I think this is about right: ``` let shouldOpenDownloadsPanel = openDownloadsListOnStart && aType == "start" && DownloadsCommon.summarizeDownloads(this._downloads).numDownloading <= 1 && browserWin == Services.focus.activeWindow; // Current behavior is for the downloads panel to always open except in the // circumstances checked above. However, the user can override this behavior by // disabling the alwaysOpenPanel pref or by disabling the downloads panel // improvements altogether. This will revert the panel to the traditional // behavior of opening the downloads panel automatically once per session. let alwaysOpen = lazy.gAlwaysOpenPanel && Services.prefs.getBoolPref("browser.download.improvements_to_download_panel"); // If we're not showing the panel, then provide a visible notification in the // topmost browser window. Also ensure that if openDownloadsListOnStart = false // is passed, we always skip opening the panel. That's because this will only be // passed if the download is started without user interaction, if a dialog was // previously opened in the process of the download (e.g. unknown content type // dialog), or if the download was created by certain context menu items. if (aType != "error" && (!shouldOpenDownloadsPanel || (this.panelHasShownBefore && !alwaysOpen))) { DownloadsCommon.log("Showing new download notification."); browserWin.DownloadsIndicatorView.showEventNotification(aType); return; } this.panelHasShownBefore = true; browserWin.DownloadsPanel.showPanel(); ```