1808893 - Multiple downloads of PDFs open in tabs, appearing to evade the "one window per click" limit on the popup blocker

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Kang Ali]

Attachment: gasskeun.html

• Summary
  For script the button is clicked, it creates a loop that creates 10 anchor elements, sets their href attribute to a URL that points to a manipulate PDF file, sets their download attribute to a filename, and simulates a click on the anchor element using the click() method.

• Reproduce

Firefox Browser Desktop Version : 108.0.2 (64-bit)
Firefox Browser Android Version : 108.1.1

For testing this script in this website : http://iecoop.id/gasskeun.html

• Impact

If Attacker set file download function creates 10 anchor elements to 100 or 1000 automatic open many tab and this disturb user Firefox

• Remediation

Blocking open new tab in function creates 10 anchor elements to download or open tab
After im research just Firefox Browser not blocking mulitple open tab, Different modern browser is blocking for this script

Thanks

Comment 1

[Kang Ali]

Attachment: Firefox_Desktop.mp4

Video POC Testing Firefox Browser Desktop

Comment 2

[Kang Ali]

Attachment: Firefox_Android.mp4

Video POC Testing Firefox Browser Android

Comment 3

[Andrew McCreight [:mccr8]]

I can't reproduce this issue on Firefox 110. I downloaded the test case, ran it, clicked on the button, then it navigated to http://iecoop.id/file10.pdf which showed a 404 error. It did not open more than one tab. Maybe the test case needs to be same origin with the downloads?

Comment 4

[Kang Ali]

(In reply to Andrew McCreight [:mccr8] from comment #3)

I can't reproduce this issue on Firefox 110. I downloaded the test case, ran it, clicked on the button, then it navigated to http://iecoop.id/file10.pdf which showed a 404 error. It did not open more than one tab. Maybe the test case needs to be same origin with the downloads?

yes Andrew this script to path download, for new test im update script in here

http://iecoop.id/gasskeun_UP.html

update path download directory upload and file DATA

Thanks

Comment 5

[Daniel Veditz [:dveditz]]

I got one PDF "popup", and in the original window an infobar telling me Firefox prevented the opening of 9 pop-up windows.

The ability to open multiple windows from a single user click was fixed in Firefox 65 (bug 675574), and still seems fixed on my build. My first instinct is to ask if you're sure you didn't grant a pop-up blocking exception to your test site, but I assume you already checked that. What's more, if you had allowed the site to open popups we should have seen the "site permission" icon next to the slashed lock icon in your movie, and it's not present. That can't be the explanation.

I just noticed that my profile has the HTTPS-only feature turned on, and that I was testing the secure https:// version of your page. I retested this in a different profile on Firefox Release and made sure I was using the "http://" slashed-lock URL for your site. When I did that I could reproduce the movie: I got ten downloads, and ten new windows showing the downloaded PDF contents. Is both cases the download URLs were on the insecure http: site.

Gijs: is there a difference in how same-origin vs cross-origin downloads are handled? In the same-origin case where I can reproduce the problem I get 10 files downloaded and then, since they are PDFs, opened in new tabs with file:// URLs. In the cross-origin case the one popup that loads is the PDF document loaded from the server and there was no download despite the download attribute. Maybe this is really just a special case of the problem bug 1306334 / bug 1463527 was trying to solve (plus our auto-opening of downloaded PDFs)

Comment 6

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Gijs: is there a difference in how same-origin vs cross-origin downloads are handled?

Not in general, though there is for the download attribute (as per spec).

In the same-origin case where I can reproduce the problem I get 10 files downloaded and then, since they are PDFs, opened in new tabs with file:// URLs. In the cross-origin case the one popup that loads is the PDF document loaded from the server and there was no download despite the download attribute.

Right, that's probably per spec - the download attribute on origin A can't override a non-download header from origin B. If B sent Content-Disposition: attachment; filename=whatever.pdf, the behaviour would be the same.

Maybe this is really just a special case of the problem bug 1306334 / bug 1463527 was trying to solve (plus our auto-opening of downloaded PDFs)

Sounds like it, yes. I didn't realize from comment 0 this was about PDF downloads. It's also not quite clear in the screencast where blank new tabs open.

I'm not sure there's any point keeping this hidden - thoughts?

Comment 7

[Daniel Veditz [:dveditz]]

Agreed, this is known behavior we'd like to change