Should auxiliary browsing contexts load fallback favicons?

[estefysc]

What is the issue with the HTML Standard?

The HTML specification states that "In the absence of a link with the icon keyword, for Document objects whose URL's scheme is an HTTP(S) scheme, user agents may instead run these steps in parallel" to fetch /favicon.ico as a fallback (https://html.spec.whatwg.org/multipage/links.html#rel-icon). However, the spec doesn't clarify whether this fallback behavior should apply to all browsing contexts, including auxiliary browsing contexts (popup windows created via window.open()).

Current browser behavior is inconsistent. Chrome does not seem to load fallback favicons for auxiliary browsing contexts, while Firefox behavior appears inconsistent. This ambiguity can cause practical issues, for example, in Web Platform Tests for Content Security Policy/Navigation (http://wpt.live/content-security-policy/navigation/javascript-url-navigation-evaluated-to-string-inherits-csp.html), fallback favicon requests in popups can trigger CSP violations that interfere with the test's intended violation reporting, causing race conditions in report delivery order.

Should the specification clarify whether the fallback favicon loading algorithm applies to auxiliary browsing contexts? If so, should it recommend that user agents skip fallback favicon loading for auxiliary contexts to align with observed behavior in major browsers and avoid unnecessary network requests for temporary popup windows?

[annevk]

Maybe we should update the tests to skip favicon fetches? It doesn't seem unreasonable to fetch these from an auxiliary context.

cc @mikewest @antosart

[antosart]

And/or we could make the tests better, so that they run independently of whether favicons are fetched or not...