Gatsby-plugin-manifest icon producing pngs and svg - but svg is not preferred icon of choice

[RyanPinPB]

Description

In gatsby-config.js I am using gatsby-plugin-manifest and my goal is to have my favicon.svg file copied into the public folder on build, and be the preferred favicon for browsers that support .svg files (Chrome).

The svg is being copied using 'auto' mode of the manifest, however, the manifest is also making .png version of the icon (as it's suppose to I believe) to be used as a backup. My issue is that Chrome is selecting to use the .png file instead of the .svg.

This svg allows for dark/light mode variations of the favicon, so I would prefer to use it.

The public index.html has two links for the icon, w/ the PNG listed after the SVG, I'm not sure if that is causing the issue.

Steps to reproduce

My github (w/ some code commented out in the gatsby-config.js file. I tried using the manual 'icons' array but the gatsby develop command stalled at the point of "buliding manifest icons"

https://github.com/RyanPinPB/pdm-gatsby

Expected result

When on a browser that supports using SVG for favicons, favicon.svg should be selected.

When browser is in dark mode, dark mode should trigger the SVG media query, causing the svg to invert colors (white/black)

Actual result

favicon-32x32.png is being selected by chrome

Environment

Run gatsby info --clipboard in your project directory and paste the output here.

gatsby info --clipboard

ERROR

UNHANDLED REJECTION (e || []).filter is not a function

TypeError: (e || []).filter is not a func tion

• envinfo.js:1
  [lib]/[gatsby-cli]/[envinfo]/dist/envin fo.js:1:73314

• task_queues.js:93 processTicksAndReject ions
  internal/process/task_queues.js:93:5

• async Promise.all

[RyanPinPB]

@moonmeister This is the favicon svg issue we talked about

[moonmeister]

So far my testing is showing that making the SVG come second fixes the issue in Chrome. But, http://dahlström.net/svg/favicon/favicon.html has the PNG coming second and works correctly, so there is something else at play here. It's maybe the "Alternate" attr in rel. I'll see if that's it, I can't find any documentation to suggest that order should affect the icon choice, it's possible this is a Bug in chrome but we'll need to narrow down the issue if it is.

[moonmeister]

Alright, this is definitely a Chrome Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1104663. Probably fairly new given someone else JUST reported it. I commented with my experience here: https://bugs.chromium.org/p/chromium/issues/detail?id=1104663#c13

Anyone having this issue should star the Chromium Bug report to indicate you've had the problem.

[ciromattia]

Comments in Chrome bugreport report that there's no "right" behaviour, though, and there are only 4 watchers so I'm expecting the current behaviour will remain for long time.

Is there any userland solution, besides forking and hacking the plugin (which I'd prefer not to do)?

[moonmeister]

Yes, we need to swap the order of the elements in DOM, I believe that also fixes this. If you'd like to open a PR that'd be appreciated.

[moonmeister]

Oh, just saw the PR thanks.