1419039 - Evalaute whether to always store both SVG and the perfectly sized icon

Status: REOPENED

(Toolkit :: Places, defect, P3)

Description

[Pierre Ossman]

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.

Comment 1

[Pierre Ossman]

Link to bug 854956?

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Marco Bonardo [:mak]]

if you wish to provide a better icon you should provide a 32x32 icon, since 16x16 is insufficient on an hi dpi screen.

Comment 4

[Marco Bonardo [:mak]]

And yes, if available we prefer svg, otherwise png with proper sizes attribute, otherwise an ico.

Comment 5

[Marco Bonardo [:mak]]

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

Comment 6

[Pierre Ossman]

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.

Comment 7

[Marco Bonardo [:mak]]

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.

Comment 8

[Marco Bonardo [:mak]]

Let's keep this open for further evaluation.

Comment 9

[Pierre Ossman]

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

Comment 10

[Marco Bonardo [:mak]]

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.