618811 - No SUMO favicon when the URL ends by #os=X&browser=Y

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task, P5)

Description

[Scoobidiver (away)]

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.

Comment 1

[Paul Craciunoiu [:paulc]]

I'd be surprised if the presence of a hash could cause this. URL?

Comment 2

[Scoobidiver (away)]

> 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.

Comment 4

[Joshua Smith [:joshua-s]]

This bug got fixed somewhere along the line.

Comment 5

[Scoobidiver (away)]

(In reply to Joshua Smith [:joshua-s] from comment #4)
> This bug got fixed somewhere along the line.
Yes, it is.

Comment 6

[Scoobidiver (away)]

Not fixed. See https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked#os=win7&browser=fx23

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

Scoobidiver: Can you provide more details about what you did? I'm seeing a favicon for that page.

Comment 8

[Scoobidiver (away)]

(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.

Comment 9

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

I'm not really able to reproduce this. Can anybody confirm?

Comment 10

[Michael Cooper [:mythmon]]

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.

Comment 11

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

WFM now.

Comment 12

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

p5 good first bug? :mikkcz still works for you on a fresh profile (see comment 10)?

Comment 13

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

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.