Can't "Go to download page" for downloads that required user interaction with HTTPS-Only interstitial error page
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
People
(Reporter: t.yavor, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [domsecurity-active])
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Reporter | ||
Comment 2•3 years ago
|
||
Sorry,
imprecised terms.
No alert page I mean HTTPS-Only error page
Reporter | ||
Comment 3•3 years ago
|
||
Sorry,
Here is the correct STR:
- Enable HTTPS-Only.
- Visit in private browsing mode https://www.thinkbroadband.com/download
- Download smallest file
- Error page displays.
- Click on Continue to site
- Save Download.
- Open Download Panel, right click on download and choose Go to download page.
Expected Result: opens https://www.thinkbroadband.com/download
Current Result: nothing happens
Reporter | ||
Comment 4•3 years ago
|
||
Thanks for pointing it out !
Comment 5•3 years ago
|
||
I retested STR in original comment, but used a PB mode window. Still can't reproduce your issue (still don't get continue to page: because the upgrade is silent), downloads panel and right click menu work as expected. Console (ctrl-shift-J) is full of download panel errors: most seem unrelated, but it's a lot of noise
The new STR in comment 3, the site just times out for me
Reporter | ||
Comment 6•3 years ago
|
||
My bad,
I am really sorry Simon. Wrong url.
I updated the STR of comment 3.
Comment 7•3 years ago
|
||
Ahh, OK, this is the same test site in Bug 1654780. I actually tested that a few days ago - clicking the links to download didn't work then, they do now. Can replicate. Here's the error
Uncaught TypeError: can't access property "originalReferrer", this.download.source.referrerInfo is null ... DownloadsViewUI.jsm:924:1
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Can you please also test using https-first
and add an automated test for it?
Reporter | ||
Comment 10•3 years ago
|
||
I tested it for https-first
and that bug doesn't exist there because we fixed it.
Here is the https-first patch which also contains an automated test it:
https://phabricator.services.mozilla.com/D122585
https://bugzilla.mozilla.org/show_bug.cgi?id=1725402
Comment 11•3 years ago
|
||
Marking this bug as blocking Bug 1704453 - if it's fixed we should land an automated test specifically for downloads
within this bug.
Updated•2 years ago
|
Comment 12•2 years ago
|
||
I can no longer reproduce this bug as originally written because of changes to the download panel in bug 1723712. In step 7 of comment 3 there is no "Go to download page" option! There is no referrer after the interstitial error page (the problem fixed for https-first mentioned in comment 10), and this menu item is now hidden when there is no referrer:
https://searchfox.org/mozilla-central/rev/26a6a38fb515dbab0bb459c40ec4b877477eefef/browser/components/downloads/DownloadsViewUI.jsm#240-245
If you retry a download from that site after you allowed the upgrade the first time there is no interstitial error, the referrer is sent, the "Go to download page" menu item appears, and it works fine.
I've changed the bug summary to something that I hope describes both the original problem as well as the current state. If we wanted we could call the original bug "fixed" -- there is no longer a broken menu item. Or we could leave it open because you still can't go to the download page, and people might want to do that. That seems like lower priority problem than a broken menu item, but I worry whether there's more security context than just the referrer that isn't getting copied to the restarted download. Since it is a download and not a document maybe that's not as relevant.
Updated•1 year ago
|