2049760 - display: none iframes pointing at content-disp: attachment resources (e.g. inside closed dialog elements) download those immediately (was: Dozens of PDF open dialog on https://app.leeto.co/espace-salarie/tableau-de-bord )

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[brice.dutheil]

Attachment: Screenshot 2026-06-23 at 17.54.12.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

I'm just navigating to the home page of this website: https://app.leeto.co/espace-salarie/tableau-de-bord

Which needs an account. I'm unsure what should I check to help narrow the issue. In the developer tools, I clearly see the GET request in the console, I also see those in the Network tab, where the initiator is a subdocument but I after that I'm not sure.

The website UI has no pdf viz. But lists some PDFs indeed.

FYI I'm no web developer, so I lack knowledge on developer tools.

Actual results:

Dozens of dialog You have chosen to open: appears telling me I want to open PDFs, but I never clicked on any link on that page.

This started to happen after Firefox 153.0b1, and still is present in 153.0b3. So I'd rather report it.

Expected results:

No dialogs.

Comment 1

[brice.dutheil]

Actually, I wrote "The website UI has no pdf viz. But lists some PDFs indeed." but by clicking in a place I never looked at before there is indeed a viewer.

In the following snippet bellow, the developer tool indicate an "event", which sugge\est it reacts to some javascript.

<a class="w-full text-inherit" data-testid="document-file-link" title="FR_PV_CSE_29_avril_2026.pdf" href="https://leclanimages.s3.eu-west-3.amazonaws.com/uploads/organisations/..._2026.pdf" target="_blank">

<div class="ant-row sc-cSaEAk sc-iXqmyu sc-heWoWI igcFli btAgNv gqiJlK css-a895m" style="margin-left: -6px; margin-right: -6px;">

<div style="padding-left: 6px; padding-right: 6px;" class="ant-col sc-cSaEAk sc-bCjwNj igcFli KBavD css-a895m">
<div class="flex size-10 min-w-10 items-center justify-center rounded-lg bg-slate-100">
<div class="flex text-lg leading-none [&amp;&gt;*]:size-full size-[18px] fill-slate-800 [&amp;&gt;*]:fill-slate-800">

<svg class="sc-FEMpB fudeIC MuiSvgIcon-root MuiSvgIcon-fontSizeMedium" focusable="false" aria-hidden="true" viewBox="0 0 24 24" data-testid="InsertDriveFileRoundedIcon"><path d="M6 2c-1.1 0-1.99.9-1.99 2L4 20c0 1.1.89 2 1.99 2H18c1.1 0 2-.9 2-2V8.83c0-.53-.21-1.04-.59-1.41l-4.83-4.83c-.37-.38-.88-.59-1.41-.59zm7 6V3.5L18.5 9H14c-.55 0-1-.45-1-1"></path></svg>

</div>
</div>
</div>

<div style="padding-left: 6px; padding-right: 6px; min-width: 0px;" class="ant-col sc-cSaEAk sc-bCjwNj igcFli dvCWOw css-a895m">
<div class="truncate">...2026.pdf</div>
<div class="ant-row sc-cSaEAk sc-iXqmyu igcFli btAgNv css-a895m" style="margin-left: -2px; margin-right: -2px; row-gap: 4px;">
<div style="padding-left: 2px; padding-right: 2px;" class="ant-col sc-cSaEAk sc-bCjwNj igcFli gdhBFr css-a895m">
<div class="flex w-fit max-w-full flex-row items-start gap-1 rounded-sm px-2 py-0.5 bg-amber-100 text-amber-800">
<span class="truncate text-xs font-medium">PV</span>
</div>
</div>

<div style="padding-left: 2px; padding-right: 2px;" class="ant-col sc-cSaEAk sc-bCjwNj igcFli gdhBFr css-a895m">
<div class="flex w-fit max-w-full flex-row items-start gap-1 rounded-sm px-2 py-0.5 bg-blue-100 text-blue-800">
<span class="truncate text-xs font-medium">Français</span>
</div>
</div>

</div>
</div>

<div style="padding-left: 6px; padding-right: 0px;" class="ant-col sc-cSaEAk sc-bCjwNj igcFli kChtVo css-a895m">
<div class="text-xs" style="color: oklch(0.372 0.044 257.287);">Added 17/06/26</div>
</div>

</div>

</a>

When this is clicked, there's some kind of embedded viewer. And looking at the html I see it's a dialog element that is open, and there many other grayed dialog elements (open is missing so they are supposedly closed).

Comment 2

[brice.dutheil]

Forgot the dialog html

<dialog class="group/modal transition-discrete duration-300 backdrop:hidden" data-testid="document-file-viewer-modal" open="">

<div class="leeto-overlay-background pointer-events-auto fixed inset-0 z-30 duration-300 group-not-open/modal:animate-out group-not-open/modal:fill-mode-forwards group-not-open/modal:fade-out group-open/modal:animate-in group-open/modal:fade-in"></div>
<div class="fixed inset-0 z-30 md:inset-14 duration-300 group-not-open/modal:animate-out group-not-open/modal:slide-out-to-bottom-30 group-not-open/modal:fade-out group-open/modal:animate-in group-open/modal:slide-in-from-bottom-30 group-open/modal:fade-in">
<div class="flex h-full flex-col bg-white duration-300 md:max-h-[80vh] md:rounded-xl md:max-h-none" data-dialog-portal="true"><div class="flex justify-between gap-4 p-4 md:p-6"><div class="w-[calc(100%-46px)]">
<div class="mb-0 truncate text-base font-semibold" title="FR_PV_CSE_29_avril_2026.pdf">FR_PV_CSE_29_avril_2026.pdf</div>
</div>

<button class="group/button relative cursor-pointer items-center gap-1 rounded-lg border border-solid font-medium border-slate-300 bg-white text-slate-900 text-sm *:text-sm flex justify-center hover:border-leeto-blue-600 hover:text-leeto-blue-600 focus:border-leeto-blue-600 focus:text-leeto-blue-600 focus:shadow-flat-leeto-blue-600 active:border-leeto-blue-800 active:text-leeto-blue-800 [&amp;.active]:border-leeto-blue-600 [&amp;.active]:text-leeto-blue-600 h-8 w-8 p-0" data-testid="modal-close-button" type="button">
<svg class="sc-FEMpB fudeIC MuiSvgIcon-root MuiSvgIcon-fontSizeMedium sc-gjcoXW hdttTS material-icons notranslate MuiIcon-root MuiIcon-fontSizeInherit" focusable="false" aria-hidden="true" viewBox="0 0 24 24" data-testid="CloseRoundedIcon"><path d="M18.3 5.71a.996.996 0 0 0-1.41 0L12 10.59 7.11 5.7a.996.996 0 0 0-1.41 0c-.39.39-.39 1.02 0 1.41L10.59 12 5.7 16.89c-.39.39-.39 1.02 0 1.41s1.02.39 1.41 0L12 13.41l4.89 4.89c.39.39 1.02.39 1.41 0s.39-1.02 0-1.41L13.41 12l4.89-4.89c.38-.38.38-1.02 0-1.4"></path></svg>
</button>

</div>

<div class="grow overflow-y-auto px-4 pt-1 pb-4 md:px-6 md:pb-6">
<iframe class="size-full align-top" src="https://leclanimages.s3.eu-west-3.amazonaws.com/uploads/organisations/..._2026.pdf" title="..._2026.pdf"></iframe>
</div>

</div>
</div>
<div class="fixed top-4 right-4 left-4 z-30 flex flex-col gap-4 md:top-auto md:right-auto md:bottom-6 md:left-6"></div>
</dialog>

Comment 3

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Calixte Denizet (:calixte)]

Attachment: server.py

Just run server.py and open http://localhost:8765/.
The served files has some iframes where src points on a pdf which is itself served as an attachment.
All the attachments are downloaded.

It isn't a pdf.js bug but more likely a File Handling one.

:Gijs, wdyt ?

Comment 5

[:Gijs (he/him)]

This is probably a duplicate of bug 832913 but that's thinking of this situation as a deliberate / malicious usecase.

Clearly (well, I'm assuming) that isn't the case here.

Reporter, I'm guessing you have PDFs set to "always ask me what to do with this file"? And I expect it goes away if you set it to "open with Firefox"? What about if you set it to "Save to disk", does it repeatedly download PDFs to disk without asking?

I suspect that the website is somehow trying to load the PDF in an iframe or similar and then tries again repeatedly if it "doesn't work" or something. Which is odd because it seems like a foolish thing to do - not all browsers will have a PDF viewer. But then, I'm surprised that they haven't noticed that it breaks in this way... perhaps Chrome or other browsers (if not configured to show PDFs inline) will not let the second or third download go through, but they will be showing a notification to users that downloads are blocked, I think...

Comment 6

[brice.dutheil]

I'm guessing you have PDFs set to "always ask me what to do with this file"?

Indeed, I have this setting.

And I expect it goes away if you set it to "open with Firefox"?

Yes, correct. And the file show properly in their embedded "HTNL dialog" UI.

Note in looking at the per file settings. I noticed there's two mime type for the pdf, application/force-download and application/pdf. Looking at the request response from amazon, the file comes with application/pdf content type.

What about if you set it to "Save to disk", does it repeatedly download PDFs to disk without asking?

Yes, but it does it each time I land on this page (or reload it), so I have many duplicates ... (n),pdf.

I suspect that the website is somehow trying to load the PDF in an iframe

Indeed, there are dozens of dialog (not open) elements, with an iframe inside, see a snippet of the dialog here : https://bugzilla.mozilla.org/show_bug.cgi?id=2049760#c2

Which is odd because it seems like a foolish thing to do - not all browsers will have a PDF viewer. But then, I'm surprised that they haven't noticed that it breaks in this way... perhaps Chrome or other browsers (if not configured to show PDFs inline)

On Chrome this doesn't happen (and I also have this ask where to save each file setting). There's no notifications suggesting the PDF is downloaded as a regular download, nothing indicate something has been blocked.
And the file appear in the embedded page viewer, when "opening" their HTML dialog.

Comment 7

[:Gijs (he/him)]

(In reply to brice.dutheil from comment #6)

What about if you set it to "Save to disk", does it repeatedly download PDFs to disk without asking?

Yes, but it does it each time I land on this page (or reload it), so I have many duplicates ... (n),pdf.

Just to clarify (and sorry for all the questions) - if you open that page once, it downloads more than one PDF? Or are you saying, it downloads just 1, but you open/reload the page many times in the course of your use of the site, and so therefore you now have many duplicates?

Which is odd because it seems like a foolish thing to do - not all browsers will have a PDF viewer. But then, I'm surprised that they haven't noticed that it breaks in this way... perhaps Chrome or other browsers (if not configured to show PDFs inline)

On Chrome this doesn't happen (and I also have this ask where to save each file setting). There's no notifications suggesting the PDF is downloaded as a regular download, nothing indicate something has been blocked.
And the file appear in the embedded page viewer, when "opening" their HTML dialog.

Right, I'm curious what happens if you disable the embedded viewer in Chrome. This would be under "Site settings" and then "additional content settings" and then for PDF switching to "Download PDF files". (of course, change it back after if you prefer)

Comment 8

[:Gijs (he/him)]

Also,

This started to happen after Firefox 153.0b1, and still is present in 153.0b3. So I'd rather report it.

I'm surprised because I don't think we've changed anything significant relating to PDF handling between 152 and 153 - though I'm only human so maybe I'm wrong - is it possible that the site changed around the same time? What version were you using before? (the Firefox update history, accessible from either Settings or Help > More Troubleshooting Information, can tell you, if you don't remember)

It's a bit tricky because Firefox will not normally let you "downgrade" your existing profile to an earlier version (because we cannot predict the future, the older build will not always know how to deal with settings etc. from the newer build).

If you're confident that a Firefox change caused this and are comfortable with the commandline (or willing to be adventurous...) you could try using https://mozilla.github.io/mozregression/ to find out what change broke the behaviour here. That won't mess with your existing profile or installs. You can configure it to use a clean profile but keep it after the first use, so that you only have to set up PDFs to 'always ask' and log in to the site once, to make the process quicker.

Comment 9

[brice.dutheil]

Attachment: server-bug-2049760.py

I looked at the server.py from :calixte and adapted it from the Leeto HTML page, that is with the dialog elements.

It appears to reproduce the issue I'm seeing on Firefox, and behave correctly on Chrome. On safari, the embedded view doesn't work that well, but at least PDFs files are not proposed to for download.

Comment 10

[brice.dutheil]

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

Just to clarify (and sorry for all the questions) - if you open that page once, it downloads more than one PDF? Or are you saying, it downloads just 1, but you open/reload the page many times in the course of your use of the site, and so therefore you now have many duplicates?

No problem for all the questions :) Let me clarify

So what I mean is that every time the browser lands on this URL then all PDFs are downloaded at once. Which means there are multiple duplicates for each PDFs that are "listed" on that webpage.

Right, I'm curious what happens if you disable the embedded viewer in Chrome. This would be under "Site settings" and then "additional content settings" and then for PDF switching to "Download PDF files". (of course, change it back after if you prefer)

Indeed the default Chrome setting is :

Sites automatically follow this setting when you visit them

• [ ] Download PDFs
• [x] Open PDFs in Chrome

When I toggle Download PDFs and reload the page, Chrome doesn't emit dozens of dialogs., instead when I click on the PDF "link" it opens the dialog, and instead of the viewer I see a gray "container" with a download link. I'll attach a screenshot.

Note that my reproducer server-bug-2049760.py exhibit the same behavior than Leeto in that case as well.

Comment 11

[brice.dutheil]

Attachment: chrome-site-settings-download-pdfs.png

Comment 12

[brice.dutheil]

Attachment: chrome-site-settings-download-pdfs-with-reproducer.png

Comment 13

[brice.dutheil]

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

Also,

This started to happen after Firefox 153.0b1, and still is present in 153.0b3. So I'd rather report it.

I'm surprised because I don't think we've changed anything significant relating to PDF handling between 152 and 153 - though I'm only human so maybe I'm wrong - is it possible that the site changed around the same time? What version were you using before? (the Firefox update history, accessible from either Settings or Help > More Troubleshooting Information, can tell you, if you don't remember)

I visit this site monthly usually, or at most every two month, I think I visited it in while on 151 (early may), as I see that I started using 152 after May 25th.
Note all are were betas, but unsure which one I used back then, as I update weekly at least.

But clearly, it's also possible that Leeto changed their site in-between 🤔. I.e. maybe they added the PDFs as a site new feature. I don't know really.

It's a bit tricky because Firefox will not normally let you "downgrade" your existing profile to an earlier version (because we cannot predict the future, the older build will not always know how to deal with settings etc. from the newer build).

If you're confident that a Firefox change caused this and are comfortable with the commandline (or willing to be adventurous...) you could try using https://mozilla.github.io/mozregression/ to find out what change broke the behaviour here. That won't mess with your existing profile or installs. You can configure it to use a clean profile but keep it after the first use, so that you only have to set up PDFs to 'always ask' and log in to the site once, to make the process quicker.

Haha, not that confident now. Unsure when I can try that. But it might be a good opportunity to rule out any regressions on FF. Moreover with the new reproducer this might simplify the process.

Comment 14

[:Gijs (he/him)]

Thanks for the extensive responses! I'm setting a reminder for myself to come back to this bug and the reproducer (thank you!) when I have more reliable infrastructure (traveling today).

Comment 15

[brice.dutheil]

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

Thanks for the extensive responses! I'm setting a reminder for myself to come back to this bug and the reproducer (thank you!) when I have more reliable infrastructure (traveling today).

Actually mozregression was kinda easy to do (the gui is quite slow, but that's ok). And it turns out this is not a regression in FF, sorry for that. So I see this behavior from way before on my reproducer. The two settings that are necessary are

**Save files to

• Ask where to save files before downloading

Files and applications

• Portable Document Format (PDF) (application/pdf) => Set to Always Ask

The reason I probably set this setting (a long while ago) that is because when I actually download a PDF, either I want to open in the system viewer or sometimes in Firefox. However, it's the first time I saw this behavior with dozens of PDFs, which now looks like a site change.

Since it's not a FF regression, I guess this is a usability issue, and Chrome looks to me how it should be handled, when the PDF itself is in an iframe ?

Comment 16

[:Gijs (he/him)]

OK, I think this would need resolving by the gecko/DOM side of things, so moving across to there and updating some descriptions.

Comment 17

[Andreas Farre [:farre]]

This is a PDF.js issue.

Looking at #loading-a-document we'll end up in the case for "application/pdf", and in the cases where the PDF viewer isn't supported, we'll fall through and eventually end up calling #handle-as-a-download. This is what's happening in this case, and the reason for this is that we have checks for Always ask where we prevent the inline rendering. That's why this happens.

Comment 18

[:Gijs (he/him)]

(In reply to Andreas Farre [:farre] from comment #17)

This is a PDF.js issue.

I'm confused by this contention. Why are we loading the document at all, given it's in an invisible subtree?

Comment 19

[:Gijs (he/him)]

Also,

If the user agent has been configured to process resources of the given type using some mechanism other than rendering the content in a navigable

... how are we in this algorithm at all if the server returns Content-Disposition: attachment, which indicates that it shouldn't be displayed (less about UA configuration, more about what the website is saying)

Edit: indeed, in https://html.spec.whatwg.org/multipage/browsing-the-web.html#populating-a-session-history-entry , step 5.5 says:

Otherwise, if navigationParams's response has a Content-Disposition header specifying the attachment disposition type:

and outlines other steps. So I don't think we should be getting to the "loading as a document" step (and then PDF.js code) at all.

Comment 20

[Andreas Farre [:farre]]

Ok, my bad. I was looking at server-bug-2049760.py in combination with Always ask and that does not set Content-Disposition. If I run server.py I get the behaviour I expect as well. With Open in ... it goes to a new tab, for ask it asks etc, but it always downloads.

If I add Content-Disposition: attachment to server-bug-2049760.py it also only ever downloads, because in that case we'll reach #populating-a-session-history-entry step 5.5 for that as well, which goes to #handle-as-a-download.(In reply to :Gijs (he/him) from comment #18)

I'm confused by this contention. Why are we loading the document at all, given it's in an invisible subtree?

Won't we run the #process-the-iframe-attributes? loading="lazy" is needed to defer loading.

So in the end, if the header exists, we do what we should (always download). If it doesn't, we either show it if the viewer allows, otherwise we download.

Comment 21

[brice.dutheil]

So in the end, if the header exists, we do what we should (always download). If it doesn't, we either show it if the viewer allows, otherwise we download.

Why not render it like chrome if the pdf is set within an iframe like in this screenshot ?

https://bugzilla.mozilla.org/show_bug.cgi?id=2049760#c12

---

That said, here's the http raw headersm, and clearly there's no Content-Dispostion header.

GET /uploads/organisations/121/teams/124/team_documents/7844/57c4d2b2-3e3f-43e2-aad9-c437de55ae8d_EN_notes_CSE_February_18_2026.pdf?X-Amz-Expires=600&
Host: ....s3.eu-west-3.amazonaws.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:153.0) Gecko/20100101 Firefox/153.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-Fetch-Storage-Access: none
Connection: keep-alive
Referer: https://.../
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Priority: u=4

HTTP/1.1 200 OK
x-amz-id-2: ...
x-amz-request-id: ...
Date: Wed, 15 Jul 2026 16:01:32 GMT
Last-Modified: Fri, 17 Apr 2026 09:34:52 GMT
ETag: "b72607dc1260843529c0d799be50903e"
x-amz-server-side-encryption: AES256
Cache-Control: no-cache
x-amz-version-id: ...
Accept-Ranges: bytes
Content-Type: application/pdf
Content-Length: 526052
Server: AmazonS3

Comment 22

[:Gijs (he/him)]

Sorry for the delay here, I've been pretty slammed in terms of workload.

Thank you to :farre and you, Brice, for all the additional details / digging.

So it seems that to do something about this, especially in the case without Content-Disposition: attachment, we'd need the PDF.js code in this situation to do something more similar to Chrome and/or <embed>, and offer a button to open/view/download PDFs, rather than falling back to a background download of PDFs. Calixte, was this ever considered?

Comment 23

[brice.dutheil]

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

Sorry for the delay here, I've been pretty slammed in terms of workload.

On my end no pressure :)
I well know the feeling.

Thank you to :farre and you, Brice, for all the additional details / digging.

Thanks you're welcome :)

So it seems that to do something about this, especially in the case without Content-Disposition: attachment, we'd need the PDF.js code in this situation to do something more similar to Chrome and/or <embed>, and offer a button to open/view/download PDFs, rather than falling back to a background download of PDFs. Calixte, was this ever considered?

In my opinion this UX approach is the better hand.

Comment 24

[Calixte Denizet (:calixte)]

So it seems that to do something about this, especially in the case without Content-Disposition: attachment, we'd need the PDF.js code in this situation to do something more similar to Chrome and/or <embed>, and offer a button to open/view/download PDFs, rather than falling back to a background download of PDFs. Calixte, was this ever considered?

Yes it has been considered in bug 1655525.
I wrote a patch for bug 1655525 which could be a good first step before fixing this one.

Comment 25

[Calixte Denizet (:calixte)]

Attachment: Bug 2049760 - Display PDFs loaded from frame attributes in PDF.js. r?farre!

Treat unsandboxed PDF loads from frame attribute processing like object/embed loads. Link-targeted navigations, sandboxed frames, and attachments keep their existing handling.

Comment 26

[Calixte Denizet (:calixte)]

Attachment: Bug 2049760 - Show the fallback for PDFs loaded from frame attributes. r?farre!

When PDF.js is disabled, use the embedded-PDF fallback for these loads; its button retry still uses normal PDF handling. Validate the actor sender before reloading with the embedder's principal.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8fcb9765c065
https://hg.mozilla.org/integration/autoland/rev/655f766cc964
Display PDFs loaded from frame attributes in PDF.js. r=farre
https://github.com/mozilla-firefox/firefox/commit/8310e944a8fd
https://hg.mozilla.org/integration/autoland/rev/c7e779a5163a
Show the fallback for PDFs loaded from frame attributes. r=farre,fluent-reviewers,flod

Comment 28

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/655f766cc964
https://hg.mozilla.org/mozilla-central/rev/c7e779a5163a

Comment 29

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/655f766cc964
https://hg.mozilla.org/mozilla-central/rev/c7e779a5163a