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


Knowledge Base Software
7 years ago
a month ago


(Reporter: Scoobidiver (away), Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: u=user c=wiki p= s=2013.backlog)



7 years ago
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?

Comment 2

7 years ago
> URL?
Any. You need to be logged out. favicon & reload the page: no favicon.


6 years ago
Component: Knowledge Base Software → General
QA Contact: kb-software → general
Component: General → Knowledge Base Software
QA Contact: general → kb-software
Duplicate of this bug: 643963
This bug got fixed somewhere along the line.

Comment 5

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

Comment 6

4 years ago
Not fixed. See
Resolution: WORKSFORME → ---
Scoobidiver: Can you provide more details about what you did? I'm seeing a favicon for that page.

Comment 8

4 years ago
(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.


4 years ago
Priority: -- → P4
Whiteboard: u=user c=wiki p= s=2013.backlog
Target Milestone: --- → Future
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.
WFM now.
p5 good first bug? :mikkcz still works for you on a fresh profile (see comment 10)?
Flags: needinfo?(mstanke)
Keywords: good-first-bug
Priority: P4 → P5
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.
Flags: needinfo?(mstanke)
You need to log in before you can comment on or make changes to this bug.