Firefox: Bookmark icon missing – /favicon.ico served as HTML

[SolunaCG]

Describe the bug

In Firefox, the favicon is displayed correctly in the browser tab but is not persisted for bookmarks.
The reason is that /favicon.ico is served as text/html (SPA fallback) instead of image/x-icon in the default setup.
Firefox can use SVG favicons, but if /favicon.ico is invalid, it will not store any bookmark icon. Chrome is more tolerant and falls back to the SVG automatically.

Steps to reproduce

1. Start the OpenCloud Docker bundle according to the official documentation (no changes, no external proxy).
2. Open the instance in Firefox.
3. Open DevTools → Network → filter for favicon.
4. Observe:

• GET /favicon.ico → Content-Type: text/html (~10 KB HTML).
• GET /favicon.svg → Content-Type: image/svg+xml (correct icon).

5. Save the site as a bookmark → the bookmark has no icon.

Expected behavior

• /favicon.ico should be a real ICO file served with Content-Type: image/x-icon.
• /favicon.svg should be served with Content-Type: image/svg+xml.
• Both paths should be excluded from SPA fallback rewrites.
• <link rel="icon"> should be included in the initial HTML pointing to these files.

Actual behavior

• Firefox receives HTML instead of an ICO file for /favicon.ico and therefore does not store a bookmark icon.
• The icon is visible in the browser tab (from the SVG) but not in bookmarks.

Setup

• Standard setup from the official Docker-Compose documentation
• https://docs.opencloud.eu/de/docs/admin/getting-started/container/docker-compose/docker-compose-base
• No external proxy or server modifications

Additional context

• Reproducible in Firefox 141.0 on Windows 10.
• Chrome does not show the issue because it falls back to the SVG icon.
• The problem occurs with the default Traefik configuration in the bundle (SPA catch-all serves HTML for /favicon.ico).

[JammingBen]

Good observation, although I disagree with the expected behavior a bit:

/favicon.ico should be a real ICO file served with Content-Type: image/x-icon.

favicon.ico should not be loaded and served at all, because we're not using it. We already have favicon.svg (or whatever the theme defines). The reason why Firefox is still requesting the .ico file is because during boostrap, there is no <link rel="icon"> tag available. It gets added after the theme has been loaded, so initially, Firefox falls back to the .ico file. I don't see a way to overcome this, since we don't have the theme and therefore the svg path available during the initial page load.

You could always setup your traefik (or whatever reverse proxy you're using) to serve some favicon.ico file. But I guess that's not something for the compose example.

@kulmann What do you think?

[SolunaCG]

Thanks a lot for the detailed explanation! 🙏

I have to admit I’m not an expert here – I only reported this as an end user because the behavior in Firefox felt unusual to me. In all other web apps I use, I’ve never had a case where a bookmark in Firefox had no favicon at all, so I thought it might be worth sharing.

From a user perspective it would just be nice if Firefox would not end up without any icon at all – whether that’s by serving a default one or in some other way. But I completely trust you to decide what makes sense technically. 🙂

[kulmann]

It's definitely ugly that there is no bookmark icon at all in Firefox. Maybe we should ship our OpenCloud favicon as default, so that we have something before the theme gets loaded. Would also mean, that instances with custom theming will have the "wrong" favicon in bookmarks. But that's still better than no icon IMO.

[SolunaCG]

Sounds great to me! From a user’s perspective, having a default favicon is definitely preferable to having no icon at all in Firefox. Thanks for considering this! I’m happy to leave the issue open and let you decide on the best approach. 🙂