Affected versions

• 92.0a1 (20210718212857)
• 91.0b4 (20210718185934)

Affected platforms

• Ubuntu 20
• Windows 10x64
• macOS 10.14.

Steps to reproduce

1. Open Firefox and Private Window.
2. Go to https://www.thinkbroadband.com/download and download a random item.
3. After the download is completed press on Go to Download page context menu from the downloads panel.

Expected result

• Link is open in a new tab.

Actual result

• Nothing happens.

Regression range

• Not reproducible with 90.0.1. I will search for one ASAP.

Notes

• Attached a screen recording.
• Sometimes the issue can be seen in normal window as well.

I tried to reproduce it with mozregression but this changelog was the best I could get,
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=597ca7dea6877156e934d52668d4ac6e60bb0826&tochange=85e7a3055098f2f8f8d7abc59d7f0d6215e47984

Note that this would say that the issue was introduced prior to Firefox 90. Can you please run mozregression and see what you get?

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)

I tried to reproduce it with mozregression but this changelog was the best I could get,
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=597ca7dea6877156e934d52668d4ac6e60bb0826&tochange=85e7a3055098f2f8f8d7abc59d7f0d6215e47984

Note that this would say that the issue was introduced prior to Firefox 90. Can you please run mozregression and see what you get?

Hello Jared! I tried finding a closer regression range around Firefox 90 using mozregression but it seems there isn't. The thing is I cannot reproduce the issue on Firefox 90.0.1 (attached a recording). So I'm thinking that is a pref or something involved. I will try again when I have the time for a manual regression, maybe mozregression is doing something.

bug 1614969 enabled mixed content download blocking (dom.block_download_insecure) on nightly only and is in the regression range, and the downloads on the test site in comment #0 are mixed content downloads. So this is presumably something to do with these being mixed content downloads.

Hm, though I can reproduce in 91 beta as well, so I guess something was broken even with the pref off?

Julian, can you help investigate here?

Looked into this today and while having dom.block_download_insecure pref set on false I got this pushlog:
Last good revision: 206721f8064a145ddb526eb9c50285fd274e7d87 (2021-06-15)
First bad revision: 36647ef6f014ee7199a0bad93851750ead132473 (2021-06-16)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=206721f8064a145ddb526eb9c50285fd274e7d87&tochange=36647ef6f014ee7199a0bad93851750ead132473 with mozregression pointing at bug 1709838.
Also while trying to do a mozregression normal search I got stuck at Firefox 80.0a1 (20200708214935) because starting with this build the files are no longer downloaded when clicked or trying to use Save link as. After some builds the files starts to download again but the Go to Download page context menu is not working. If more information is needed please let me knwow.

(In reply to Alexandru Trif, QA [:atrif] from comment #5)

Looked into this today and while having dom.block_download_insecure pref set on false I got this pushlog:
Last good revision: 206721f8064a145ddb526eb9c50285fd274e7d87 (2021-06-15)
First bad revision: 36647ef6f014ee7199a0bad93851750ead132473 (2021-06-16)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=206721f8064a145ddb526eb9c50285fd274e7d87&tochange=36647ef6f014ee7199a0bad93851750ead132473 with mozregression pointing at bug 1709838.

This makes sense, thanks!

Christoph, can you (or Julian or :sstreich) take a look here? This regression is going to ship to users with 91, it'd be nice if we can fix it in 92 at least. :-(

Basti is on it ...

Backed out for causing xpcshell failures on test_DownloadLegacy.js.

Push with failures

Failure log

Backout link

Backed out changeset 1c892391a0e1 (Bug 1721146) for causing dt failures in browser_console_clear_cache.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/cbf48d682c99e8722c85530e0418088e60b91c41
Push with failures, failure log.

Hi Nicolas, could you help me understand this failure? from the failure log the patch looks related, on my own try run it seems to pass on linux but fail on mac/windows.
Is there a way making sure downloads are saved in the download history with the right referrerinfo might impact this?

This looks like Bug 1479876 and shouldn't be related to your patch. The failure screenshot shows the same issue I saw when quickly investigating it.

https://hg.mozilla.org/mozilla-central/rev/60399b6a990a

Hello! Tried verifying today and it seems that I can still reproduce the issue with Firefox 92.0a1 (20210808090543) on Windows 10x64. The issue is reproducible with dom.block_download_insecure on false or true as well inside private windows.

(In reply to Alexandru Trif, QA [:atrif] from comment #17)

Created attachment 9235330 [details]
download_04.gif

Hello! Tried verifying today and it seems that I can still reproduce the issue with Firefox 92.0a1 (20210808090543) on Windows 10x64. The issue is reproducible with dom.block_download_insecure on false or true as well inside private windows.

Can you verify the bug is fixed with dom.block_download_insecure set to true, but dom.security.https_first_pbm set to false ? That appears to work for me. If you can verify the same, can you please file a bug for the fact that dom.security.https_first_pbm still breaks this functionality, and make it depend on bug 1725402 (where I suspect fixing that will fix the issue) ?

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

(In reply to Alexandru Trif, QA [:atrif] from comment #17)

Created attachment 9235330 [details]
download_04.gif

Hello! Tried verifying today and it seems that I can still reproduce the issue with Firefox 92.0a1 (20210808090543) on Windows 10x64. The issue is reproducible with dom.block_download_insecure on false or true as well inside private windows.

Can you verify the bug is fixed with dom.block_download_insecure set to true, but dom.security.https_first_pbm set to false ? That appears to work for me. If you can verify the same, can you please file a bug for the fact that dom.security.https_first_pbm still breaks this functionality, and make it depend on bug 1725402 (where I suspect fixing that will fix the issue) ?

Yes I can confirm that this is working as intended if dom.block_download_insecure"true/ dom.security.https_first_pbm:false on Windows 10x64 and macOS 10.15 with Firefox 92.0b2 and 93.0a1 (20210812092607). Logged bug 1725408 as requested. Thank you!

(In reply to Alexandru Trif, QA [:atrif] from comment #19)

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

(In reply to Alexandru Trif, QA [:atrif] from comment #17)

Created attachment 9235330 [details]
download_04.gif

Hello! Tried verifying today and it seems that I can still reproduce the issue with Firefox 92.0a1 (20210808090543) on Windows 10x64. The issue is reproducible with dom.block_download_insecure on false or true as well inside private windows.

Can you verify the bug is fixed with dom.block_download_insecure set to true, but dom.security.https_first_pbm set to false ? That appears to work for me. If you can verify the same, can you please file a bug for the fact that dom.security.https_first_pbm still breaks this functionality, and make it depend on bug 1725402 (where I suspect fixing that will fix the issue) ?

Yes I can confirm that this is working as intended if dom.block_download_insecure"true/ dom.security.https_first_pbm:false on Windows 10x64 and macOS 10.15 with Firefox 92.0b2 and 93.0a1 (20210812092607). Logged bug 1725408 as requested. Thank you!

Thanks! Marking this as verified fixed per this comment.