[pl4nty]

Problem

Discord CDN PDF links hang. Discord serves them with Content-Type: application/pdf and Content-Disposition: attachment. Inline PDFs open in pdf.js, and non-PDF attachments download, so neither of those is affected.

Root cause

• GeckoView sets browser.download.open_pdf_attachments_inline=true (geckoview-prefs.js). An attachment PDF is therefore rendered internally instead of being handed to onExternalResponse.
• DocumentLoadListener GetWhereToOpen retargets an internally rendered attachment into a new tab (browser.link.open_newwindow=3).
• That retarget reaches Candy as onLoadRequest with uri="", target=TARGET_WINDOW_NEW and no user gesture. BrowserController denies it, and the original load never finishes. I confirmed this sequence by logging on the emulator: uri=[] redirect=false direct=false target=2, then decision=Deny.

Fix

Set browser.download.open_pdf_attachments_inline=false in the existing Gecko startup prefs file. Attachment PDFs then go through onExternalResponse and download like other attachments, which matches what the Content-Disposition header asks for. Inline PDFs still open in pdf.js.

Testing

Tested on an emulator (API 35, debug build, GeckoView 157), although there were some extra patches applied:

• Before the fix: PageStart, then the empty new-window request is denied, and the page stays pending indefinitely.
• After the fix: PageStart then PageStop. The download notification shows "Download complete", and /sdcard/Download/<redaced>.pdf is 5,596,553 bytes, which matches the server's content-length.
• I updated GeckoHistoryCacheConfigInstrumentedTest to expect the new pref.

The alternative fix is to accept the retarget and open the PDF in a new Candy tab with pdf.js, which is what Firefox does. That needs the popup and new-session path to accept an empty-URI, gesture-less window, which I suspect is a much larger change.