Discourse URL changes after scroll cause the browser to request the favicon over and over and over (at least in Chrome)
-
Scrolling in topics seems to cause discourse to request the favicon over and over and over:
It gets loaded from the device cache, so it's not a bad hit on data, but it seems kind of odd to constantly reload it like that.
EDIT: This has been nailed down to the URL change after scroll instigating the browser to re-request the favicon. I have no idea if symlinking the favicion as favicion.ico instead of setting the relative link in the HTML would solve the problem, but it might help. Browsers might not obey your request to cache the file.
##Solution (On Chrome):
It's definitely related to the icon link in the HTML on Chrome. It can be fixed by somehow putting the favicon at favicon.ico, e.g. symlink the favicon file toprotocol://domain.tld/favicon.ico
.Test bad HTML:
<!DOCTYPE html> <html> <head> <link rel="icon" href="favicon/favicon.ico" /> </head> <body> <script> var i = 0; var url = window.location; setInterval(function() { history.replaceState(window.location + "#" + i++); console.info(window.location + "#" + i); }, 1000); </script> </body> </html>
Test good HTML:
<!DOCTYPE html> <html> <head> </head> <body> <script> var i = 0; var url = window.location; setInterval(function() { history.replaceState(window.location + "#" + i++); console.info(window.location + "#" + i); }, 1000); </script> </body> </html>
You'll have to supply your own favicon, sorry.
-
It gets loaded from the device cache if your browser is sane
Not a good buttumption to make
Also, that's hillarious.
-
Not a good buttumption to make
Meaning it obeys Cache-Control, and Expires headers? Then yeah. There should still be an ETag header so that you can send a 302, but that doesn't mitigate the stupidity of opening up an HTTP connection for every scroll.
-
Well, all browsers should obey those. As we all know though........
-
Scrolling in topics seems to cause discourse to request the favicon over and over and over
Discourse, or browser?
-
Hmm, that's a good question...
-
It might be a side effect of constantly changing the URL ....
EDIT: Yeah that looks like the issue - the Referer header is different in each request, causing the favicon "request". Thankfully it looks like Chrome is smart enough not to actually send that request, it just lists it as a 200 (probably because it's not even bothering to ask if it was modified from the server so 304 would be inappropriate).
EDIT2: Yeah, fiddler isn't showing the requests, so they're not being made, but only because Chrome is being smart. I wonder how other browsers behave.
-
I think that might be it. Which is... one of many reasons there are issues with the way Discourse does things
-
I think that might be it. Which is... one of many reasons there are issues with the way Discourse does things
It might be because their Date and Expires are the same thing .... though it does have a Cache-Control: max-age
NM - they're a year apart
-
Well, no browser I tried obeys the replaceState() history API method, so I don't really have faith in them.
And whatever MDN claims, yes, even FF gets it wrong. Basically, both
pushState
andreplaceState
spam your history in the same way.
-
Well, no browser I tried obeys the replaceState() history API method, so I don't really have faith in them.
And whatever MDN claims, yes, even FF gets it wrong. Basically, both
pushState
andreplaceState
spam your history in the same way.I think this is a different issue from history spam - favicon requests are, generally, subordinate to every page request if there is a favicon link header set.
This http request spam is probably a side effect of not having the favicon in the root as favicon.ico
-
It is, just venting my frustrations, never mind me
-
Scrolling in topics seems to cause discourse to request the favicon over and over and over:
I can see it now:
@codingwhorror said:
CLOSED, NOT_A_BUG, AS_DESIGNED, WORKAROUND_EXISTS
-
I can see it now:
@codingwhorror said:
CLOSED, NOT_A_BUG, AS_DESIGNED, WORKAROUND_EXISTS
<img src="/uploads/default/20329/5f8b2d83a3cad232.png" width="335" height="40">
My bet is it's per HTML spec, that doesn't make it not a bug - see my edit of the OP for my tests on Chrome.