There is no SUMO favicon on the left side of the location bar when the SUMO URL ends by #os=X&browser=Y whatever X and Y.
I'd be surprised if the presence of a hash could cause this. URL?
> URL? Any. You need to be logged out. http://support.mozilla.com/en-US/home/: favicon http://support.mozilla.com/en-US/home/#os=win&browser=fx4 & reload the page: no favicon.
This bug got fixed somewhere along the line.
(In reply to Joshua Smith [:joshua-s] from comment #4) > This bug got fixed somewhere along the line. Yes, it is.
Not fixed. See https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked#os=win7&browser=fx23
Scoobidiver: Can you provide more details about what you did? I'm seeing a favicon for that page.
(In reply to Will Kahn-Greene [:willkg] from comment #7) > Scoobidiver: Can you provide more details about what you did? I'm seeing a > favicon for that page. New profile, signed out or signed in.
I'm not really able to reproduce this. Can anybody confirm?
On a fresh profile, I can reproduce this. Any hash I put on the url from comment #6 prevents the favicon from working. That's really puzzling.
p5 good first bug? :mikkcz still works for you on a fresh profile (see comment 10)?
Still cannot reproduce this. I have tested in Nightly with used profile, Firefox release with fresh profile and Brave with no data. Looking at the DOM (from DevTools after any JS manipulation) it looks exactly the same, at least on the pages mentioned above. The fragment (everything behind the hashmark) is not even sent to the server, so the only option is to be caused by some JS manipulation. Maybe something related to show-for doing some unsafe replacement in the whole DOM? The icons are defined as firefox-16.png, firefox-32.png, firefox-64.png etc. So in case show-for replaces firefox-VERSION for something else, it may happen to break the icon definitions. But that probably happens when the default version matches some of the icons. But that's just a theory.