Closed Bug 1721146 Opened 3 years ago Closed 3 years ago

Go to download page context menu option no longer working in Private Window

Categories

(Firefox :: Menus, defect, P1)

Product:
Firefox
Component:
Menus
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
92 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- disabled
firefox90 --- disabled
firefox91 --- wontfix
firefox92 --- verified

People

(Reporter: atrif, Assigned: sstreich)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

Attachments

(4 files)

download_01.gif
2.23 MB, image/gif
Details
download_02.gif
2.36 MB, image/gif
Details
Bug 1721146 - Fix Missing ReferrerInfo on Blocked Downloads r=Gijs
48 bytes, text/x-phabricator-request
Details | Review
download_04.gif
3.26 MB, image/gif
Details
Attached image download_01.gif —

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.
Has Regression Range: --- → no
Has STR: --- → yes

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?

Flags: needinfo?(alexandru.trif)
QA Whiteboard: [qa-regression-triage]
Attached image download_02.gif —

(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.

Blocks: 1685479
status-firefox90: unaffected → disabled
status-firefox91: wontfix → disabled
Keywords: regressionwindow-wanted
Regressed by: 1614969

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?

status-firefox91: disabled → wontfix
Flags: needinfo?(julianwels)
Keywords: regressionwindow-wanted

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.

Flags: needinfo?(alexandru.trif)

(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. :-(

Flags: needinfo?(ckerschb)
Regressed by: 1709838

Basti is on it ...

Assignee: nobody → sstreich
Status: NEW → ASSIGNED
Flags: needinfo?(julianwels)
Flags: needinfo?(ckerschb)
Priority: -- → P1
Whiteboard: [domsecurity-active]
See Also: → 1723712
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/autoland/rev/6bcd0226a473
Fix Missing ReferrerInfo on Blocked Downloads r=Gijs

Backed out for causing xpcshell failures on test_DownloadLegacy.js.

Push with failures

Failure log

Backout link

Flags: needinfo?(sstreich)
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/autoland/rev/1c892391a0e1
Fix Missing ReferrerInfo on Blocked Downloads r=Gijs
Flags: needinfo?(sstreich)

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.

Flags: needinfo?(sstreich)

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?

Flags: needinfo?(sstreich) → needinfo?(nchevobbe)

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.

Flags: needinfo?(nchevobbe)
Pushed by mozilla@christophkerschbaumer.com:
https://hg.mozilla.org/integration/autoland/rev/60399b6a990a
Fix Missing ReferrerInfo on Blocked Downloads r=Gijs

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

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox92: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Blocks: 1724545
Attached image 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.

Flags: needinfo?(sstreich)

(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) ?

Flags: needinfo?(sstreich) → needinfo?(alexandru.trif)

(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!

Flags: needinfo?(alexandru.trif)

(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.

Status: RESOLVED → VERIFIED
status-firefox92: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: