2015285 - Firefox requested the file "favicon.ico" every time after opening a PDF file

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Peter Kranich]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

After I signed up on the page "mydomain" I opened some PDF files there. When I wanted to open the fourth file, the page was suddenly unavailable.
The reason for this was: Firefox requested the file "favicon.ico" every time after opening a PDF file. However, not in the context of my browser session, which led to the error 401, although the file exists.
And three times error 401 means fail2ban locks my IP for an hour.

Actual results:

Apache-Log:

mydomain:443 111.222.33.44 - user [07/Feb/2026:09:39:25 +0000] "GET /index.htm HTTP/1.1" 200 5785 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0"
mydomain:443 111.222.33.44 - user [07/Feb/2026:09:39:25 +0000] "GET /favicon.ico HTTP/1.1" 200 2601 "https://mydomain/index.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0"
mydomain:443 111.222.33.44 - user [07/Feb/2026:09:41:00 +0000] "GET /File1.pdf HTTP/1.1" 200 388933 "https://mydomain/index.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0"
mydomain:443 111.222.33.44 - - [07/Feb/2026:09:41:01 +0000] "GET /favicon.ico HTTP/1.1" 401 3385 "https://mydomain/File1.pdf" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0"

Expected results:

Open favicon.ico in the context of my browser session.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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 2

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello, thank you for the bug report!

Unfortunately I could not reproduce your issue. All the pdf's were opened without any issue. Would you be so kind as to answer a few questions so we can investigate this further?

• Are there any other settings needed in order to reproduce?
• Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
• Does this issue happen with latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
• Does this issue happen when Firefox is in Troubleshoot Mode? Here’s a link on how to enable it: https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-troubleshoot-mode

Thank you.

Comment 3

[Peter Kranich]

Attachment: Firefox-PDF-Request-Error.pdf

Hints to reproduce the issue

Comment 4

[Peter Kranich]

The issue happens also with a new installed FirefoxPortableNightly (149) with no plugins or in "Troubleshoot Mode".
See also new attached PDF file for needs to reproduce the issue.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:calixte, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Calixte Denizet (:calixte)]

Attachment: Bug 2015285 - Use the page's content principal for favicon requests when PDF.js owns the document r=Mossop

PdfStreamConverter sets aRequest.owner to a resource://pdf.js/ principal,
so the resulting document's nodePrincipal is resource://pdf.js/ even though
its URI is the original https:// PDF URL. FaviconLoader was forwarding that
resource:// principal as the favicon channel's loadingPrincipal, causing the
HTTP auth cache lookup to miss credentials that were cached for the https://
origin, which in turn sent unauthenticated favicon requests.

When the document node's principal is resource://pdf.js, substitute a content
principal derived from the page URI (preserving the origin attributes) and
pass null for the loading node. Passing null is necessary because LoadInfo
derives mLoadingPrincipal from the node's NodePrincipal() when a node is
provided, ignoring the explicit aLoadingPrincipal argument.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:calixte, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9810aa239295
https://hg.mozilla.org/integration/autoland/rev/4ddecb1464bb
Use the page's content principal for favicon requests when PDF.js owns the document r=mossop

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/4ddecb1464bb