Open Bug 1419039 Opened 3 years ago Updated 3 years ago
Evalaute whether to always store both SVG and the perfectly sized icon
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171113102034 Steps to reproduce: Something changed for the worse in favicon handling in Firefox 57. The previous behaviour was to grab the last declared favicon. So web sites made sure to have a 16x16 image declared last. However Firefox now grabs any SVG one and scales it down to 16x16. Unfortunately that looks horrible in many cases. Example site is http://novnc.com. IMO Firefox should grab the icon that has a matching size first, using "any" if nothing else fits.
Link to bug 854956?
This is a regression from bug 1352459 5:18.89 INFO: No more inbound revisions, bisection finished. 5:18.89 INFO: Last good revision: 4dc8f5f9259c1413dcd2755ae01bad8dc8139050 5:18.89 INFO: First bad revision: 6d5fe3151e733d6ac818728f44f5985f1aa63f8c 5:18.90 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4dc8f5f9259c1413dcd2755ae01bad8dc8139050&tochange=6d5fe3151e733d6ac818728f44f5985f1aa63f8c I used http://mversen.de/mozilla/bug1419039/ for testing -> 2 different favicons to better see the difference
Status: UNCONFIRMED → NEW
Ever confirmed: true
if you wish to provide a better icon you should provide a 32x32 icon, since 16x16 is insufficient on an hi dpi screen.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
And yes, if available we prefer svg, otherwise png with proper sizes attribute, otherwise an ico.
I actually wonder if the problem is the use of --moz-crisp-edges on the icon. unfortunately we can't just remove that, because many pages still only serve 16x16 icons
But this is not a hi dpi screen. So Firefox is not following the spec and picking the most suitable icon. Firefox needs a 16x16 icon. The page provides a 16x16 icon. All other icons should be ignored at that point. "any" is very unspecific in what it is designed for so it should be a fallback, not the first hand choice.
There's no strict specification on icons, you declare what is available and the client tries to do a best pick, there's no agreed upon standard on what to pick. The pick may not always be perfect, because what works better on Site A, may look ugly on Site B. The only client side solution I'd see would be to store both icons, taking a lot more space, because we need both a small icon and a larger one for different kind of UIs. That's why in general we prefer SVG. Storing both icons would undergo a network, space and I/O hit, that needs to be evaluated. Another solution, server side, could be to improve the svg icon to make it scale better, or provide an ico with multiple frames instead of the svg, or even multiple separated pngs. Note that hi-dpi screens are more and more common nowadays, also on Windows it is very common to use 125% or 150% scale factors, thus we must support that case.
Let's keep this open for further evaluation.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: firefox prefers SVG favicon [regression] → Evalaute whether to always store both SVG and the perfctly sized icon
Component: General → Places
Priority: -- → P3
Product: Firefox → Toolkit
Summary: Evalaute whether to always store both SVG and the perfctly sized icon → Evalaute whether to always store both SVG and the perfectly sized icon
I firmly believe that it is impossible to make do with just a single icon given the varied use they've gotten. So I think you need to be able to store multiple icons. This has to do with human vision rather than technical limitations. Unfortunately the standards don't fully support this, so I've also opened an issue with whatwg: https://github.com/whatwg/html/issues/3245
I must clarify, we already DO store multiple icons, this is a case where we may want to store even more. It has costs clearly.
You need to log in before you can comment on or make changes to this bug.