1311665 - After 5 downloads the download pop up is not displayed

Status: REOPENED

(Firefox :: Downloads Panel, defect, P3)

Description

[Cristian Comorasu, QA [:ccomorasu], Release Desktop QA]

[Affected versions]:

 Fx51.0a2

[Affected platforms]:

 Windows 10 x64
 Windows 8.1 x64
 Mac OS X 10.11
 Ubuntu 14.04 LTS
 
[Steps to reproduce]:

 1. Launch Firefox.
 2. Go to " http://www.thinkbroadband.com/download.html ".
 3. Download 7 very large file.

[Expected result]:

 The new download pop-up is displayed after every click on new download.

[Actual result]:

 The new download pop-up is not displayed after the 5th download.

[Additional notes]:

 After one of the first 5 downloads is finished, the pop-up is displayed. There are only 5 downloads at a time, and no pending downloads in the download panel.

Comment 1

[Ben Tian (inactive)]

Cristian,

Please attach screenshot of "download pop-up" you mean. I am unsure which pop-up you are referring to.

Comment 2

[Cristian Comorasu, QA [:ccomorasu], Release Desktop QA]

Attachment: NewDownloadPopUp.PNG

Comment 3

[Cristian Comorasu, QA [:ccomorasu], Release Desktop QA]

Hello Ben,

 I added an attachment with the pop-up I was talking about. 
This pop-up appears every time you click for a new download. On Windows after 5 ongoing downloads the new download pop-up isn't displayed until one of the downloads is finished. However on Mac and Ubuntu this issue is reproducible after 6 new downloads.

 Also this issue is reproducible on Fx50.0b9.

[Regression Range]:

 This issue is not a recent regression, it reproduces back to Fx version 30.0.

Comment 4

[Ben Tian (inactive)]

Per comment 3, this bug doesn't result from download panel redesign landed in Fx 51 since it exists since Fx 30.

Paolo, can you help check this download panel bug since Fx version 30.0?

Comment 5

[:Paolo Amadini]

The fact that we don't display too many handler choice dialogs is a good thing, although I'm not aware of any code that enforces this limit, so like Cristian observed the limit might depend on the behavior of the platform.

Anyways, I don't think there should be no limit, and ideally we should display just one handler choice dialog at a time. We have bug 1271118 on file that is closely related to the issue described here, I'm marking this one as a duplicate.

We're also working towards removing the handler choice dialog completely, so these bugs would be automatically resolved once that is done.

Comment 7

[Masatoshi Kimura [:emk]]

I don't think that this bug should be duplicated to bug 167475. The reporter did not visit to a malicious website that uses <iframe> to open a lot of "Opening" dialog. It will happen even with 6 (or 7) <a href=> links.

I don't even think that this bug was a duplicate of bug 1271118. Although 5 (or 6) downloads are in progress, only ONE "Opening" dialog is open at a time.

Cristian, could you still reproduce this problem with the latest version of Firefox?

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

FYI - I was doing little cleaning and I marked this bug as duplicate of bug #167475 to prevent duplicate of duplicates, as this bug was marked as duplicate of bug #1271118 and bug #1271118 was duplicate of bug #167475.

Comment 9

[Cristian Comorasu, QA [:ccomorasu], Release Desktop QA]

Hello!
Using the latest nightly (Fx 65.0a1 2018-12-27)the download pop-up is no longer displayed after 9 large downloads(9 items can be downloaded at a time).

Comment 10

[Masatoshi Kimura [:emk]]

Reopening as this is not a duplicato of bug 167475 (nor even bug 1271118).

I think that the download hits the max connection limit.

Toplevel URI load will set the UrgentStart flag (and then NS_HTTP_URGENT_START):
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/docshell/base/nsDocShell.cpp#10787-10796
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpChannel.cpp#6698-6702

When NS_HTTP_URGENT_STARTflag is set, the max connection is mMaxUrgentExcessiveConns (default 3) + maxPersistConns (default 6 for persistent connections). This is consistent with the number 9.
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpHandler.cpp#1269-1276
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpHandler.cpp#1277-1279
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpConnectionMgr.cpp#1045-1051
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpConnectionMgr.cpp#2975-2976
https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/protocol/http/nsHttpHandler.cpp#1292-1297

When this bug was filed, the concept of UrgentStart did not exist, so the number (6) was consistent with maxPersistConns.