Regression? Apple touch instead of favicon displayed again as favicon (Firefox)

ux
1

Pinging @ashledombos - do we have a regression here? My users and I observe exactly the bahavior you describe in the closed topic:

Continuing the discussion from Apple touch instead of favicon displayed as favicon (Firefox):

…but: I do have absolute URLs, and Firefox shows the Apple Icon in the tabs and bookmarks instead of the favicon:

<meta name="generator" content="Discourse 1.5.0.beta2 - https://github.com/discourse/discourse version 992386b22e59758411215b37d66eab445d1060b1">
<link rel="icon" type="image/png" href="https://static1.macmini-forum.de/images/favicon.ico">
<link rel="apple-touch-icon" type="image/png" href="https://static1.macmini-forum.de/apple-touch-icon.png">
<link rel="icon" sizes="144x144" href="https://static1.macmini-forum.de/apple-touch-icon.png">
<meta name="theme-color" content="#ffffff">
6 Likes
2

Well, in fact from my side it’s half fixed, but I did not notice before the topic was closed:

With absolute URLs,

  • When connected, the favicon is correct
  • When disconnected, the favicon is the Apple touch icon

With relative URLs it’s always the Apple touch

1 Like
3

Am I the only one deploying a Apple touch icon with a Firefox user base? No one else noticed this?

Or are we silently blaming this on Firefox? Clearly, also here on Meta we have this issue: Firefox pulls the biggest icon and does a lousy job scaling it down:

…while Chrome pulls the favicon in the first place and looks much slicker:

5 Likes
4

I am not sure I understand. So you are saying if both favicon and apple touch are specified, Firefox uses the apple touch and fails to scale it correctly? I need a clearer, simpler, “explain it to me like I am four years old” explanation.

1 Like
5

Short version: yes.

Longer version, as explained here:

Some browsers, such as Android Firefox, tend to load the largest PNG icon they find. This behavior is arguable and it has at least a drawback: it can conflict with the 192x192 icon dedicated to Android Chrome. Suppose you designed the Android Chrome icon with a drop shadow. You don’t expect to see this picture in other browsers. The workaround to this issue is to generate an “even larger icon”.

Not exactly sure how we can handle this - either revert to a non-touch-icon version, or stuff an 194x194 version into your favicon… :frowning:

5 Likes
6

@codinghorror I have the exact same problem.

4y old : favicon.png doesn’t show up as the site icon. Apple touch icon show up instead as the site icon.
It only happen in Firefox.

That’s just it.

3 Likes
7

If I understand the page @JSey linked and the corresponding FireFox bug report correctly, it seems that this could be fixed by moving the 16x16 favicon definition to the end, because FF loads all favicons (ignoring size specifications) and than always sticks to the last one specified.

I do not know how other browsers would be affected by this. Maybe specify the 16x16 icon twice, at the beginning and the end?

1 Like
9

I am experiencing the same problem. Discourse inserts three <link rel> in the web page.

  1. <link rel="icon" href="FAVICON"> The actual favicon item. Currently Discourse also prints type="image/png", although one may have uploaded a .ico file image/x-icon.
  2. <link rel="apple-touch-icon" ... The apple touch icon.
  3. <link rel="icon" sizes="144x144" href="APPLE TOUCH ICON"> The rel="icon" attribute will tell Firefox that this is a favicon. Firefox loads the file as favicon and overrides item no. 1.

I tested with Firefox 49 and removing item no. 3 causes Firefox to correctly load the favicon, without affecting the apple touch icon. So my question:

Why is it item 3 even produced? It is not needed for either favicon or apple touch icon; moreover, it links to the wrong file (the apple touch icon rather than the favicon). Favicons and Touch icons serve two completely different purposes and in particular the latter has very different styling conventions, so they should not be mixed up in my opinion. Removing it would fix the visualization issues.

Why is the mime type and the size hardcoded? The browser will anyway deduce this, and hardcoded sizes are no useful, unless the media really matches. But then it would make sense to provide more sizes for the same media, which is the reason why originally the attribute size exists. If only one media is provided, the size doesn’t matter.

My suggestion is to drop item 3. and all the sizes and type attributes.

edit: Tested on iPad, iPhone, Firefox 49, Chrome 53, it seems to work smoothly and displays the correct icons.
I created a PR.

5 Likes