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 to protocol://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.


  • :belt_onion:

    @rad131304 said:

    It gets loaded from the device cache if your browser is sane

    Not a good buttumption to make
    Also, that's hillarious.



  • @sloosecannon said:

    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.


  • :belt_onion:

    Well, all browsers should obey those. As we all know though........


  • FoxDev

    @rad131304 said:

    Scrolling in topics seems to cause discourse to request the favicon over and over and over

    Discourse, or browser?


  • :belt_onion:

    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.


  • :belt_onion:

    I think that might be it. Which is... one of many reasons there are issues with the way Discourse does things



  • @sloosecannon said:

    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


  • BINNED

    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 and replaceState spam your history in the same way.



  • @Onyx said:

    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 and replaceState 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


  • BINNED

    It is, just venting my frustrations, never mind me 😛



  • @rad131304 said:

    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



  • @abarker said:

    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.


Log in to reply