Favicons are being requested on every hashchange
Reported by
zac.spit...@gmail.com,
May 12 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3096.0 Safari/537.36 Steps to reproduce the problem: 1. open http://temp.paulirish.com/revalidate/ 2. open dev tools network panel 3. add #1 to the url 4. change the hash to #2 5. change the hash to #3 What is the expected behavior? favicon should not be downloaded for each hash change (this demo is loading from cache) What went wrong? there is a favicon request for each hashchange Did this work before? N/A Does this work in other browsers? Yes Chrome version: 60.0.3096.0 Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 26.0 r0
,
May 12 2017
Reproduced with BrowserStack, using Chrome 36, 50 and 57 on Windows 10 and Chrome 58 on macOS Sierra. Also reproduced using Chrome 58 on Windows 7. (I used chrome://net-internals for testing Chrome 36, because the requests are not exposed in the Developer Tools on that version) I assume this is relevant to all of the Blink based platforms.
,
May 12 2017
Tested the issue on Latest Canary# 60.0.3097.0 and is reproducible on Windows, Mac and Linux. This is a Non-Regression issue existing from M44# 44.0.2403.157. Changing the status to Untriaged, so that the issue would get addressed. Thank You.
,
May 12 2017
This is unrelated to the Developer Tools. The browser really initiates those requests and not because of the Developer Tools. You can use chrome://net-internals to see it even when the Developer Tools feature is not active.
,
May 12 2017
I do see a request for the favicon but it hits the disk cache if it's setup with cache-control / etc... Not sure if there is any reason why we shouldn't put favicons into the/a memory cache. P3 as this is doesn't sound like a major data usage concern. Re hotlist-interop: did anyone check the other browsers? do they hit the memory cache?
,
May 12 2017
pkotwicz@: Can you help triage?
,
May 12 2017
The issue is that we are not stripping the fragment prior to saving the favicon in the database. Fixing this is not a high priority (we have never stripped the fragment) but it would be a straightforward fix
,
May 12 2017
You could argue there is some value in saving the fragment part (dynamic favicons per fragment), but I am not sure Chrome should be so eager to update the favicon by itself. If a <meta rel="icon"> exists and it changed, it is understandable to query it again (but that would happen regardless of the hashchange). But if it is browser originated (the default origin/favicon.ico)... That seems overly excessive. Especially since you do not include the fragment in the referrer anyway.
,
May 13 2017
this is a regression between current stable and canary, in stable there's no activity logged in the network panel for a hashchange. In canary there's a request logged in the network panel for each favicon, each time and a site may have multiple favicons with different sizes i.e. sizes="192x192", sizes="96,96". so this problem ends up spamming the network panel with a lot of redundant noise, i can provide an example (via email, don't want to post here publically) which demonstrates this problem in a single page app
,
May 13 2017
#9 - I have not seen a regression by following the steps that you provided (I saw a long standing bug). It would be great if you could create a small public test case (you can use plnkr.co or github.com for quickly hosting files) that shows the regression.
,
May 13 2017
ok, here is a reduced test case http://run.plnkr.co/IQaH4hIe1wm5Pnp6/#1 http://plnkr.co/edit/rTcelKdUEFBzQpGQJt7i if you edit out the last line in the <head> section, stable behaves the same as canary <link rel="shortcut icon" href="https://www.google.com/favicon.ico">
,
Jun 29 2017
,
Oct 10 2017
and now with the latest canary update, this is also triggering the SSL certificate warning too for every hashchange for each favicon
,
Jun 4 2018
I've been noticing this too; seeing a lot of server requests for favicons in a single-page app. I'd appreciate a fix, it'd save me some bandwidth!
,
Aug 2
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ajha@chromium.org
, May 12 2017