Favicon not appearing in bookmark
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
People
(Reporter: sayantan.santra689, Unassigned)
Details
Attachments
(1 file)
|
6.19 KB,
image/png
|
Details |
The empty bookmark towards the right is the faulty one.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
- Open the website for a local cockpit installation
- Add it to bookmarks bar
Actual results:
Favicon did not appear in the bookmarks bar, even though it appears in the website.
Expected results:
Favicon should have apepared.
|
Reporter | |
Comment 1•3 years ago
|
||
The favicon does appear when I add it as a proxy thgough Nginx reverse proxy.
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•3 years ago
|
||
I didn't manage to reproduce this bug on Ubuntu 22.04 using the latest version Firefox 106.0.5: the favicon of the page https://cockpit-project.org/ is properly displayed in the Toolbar after being bookmarked.
Could you please elaborate how did you bookmark this page (using CRTL+D or other method)?
Did you notice this issue on any other Firefox version? Do you manage to reproduce it in Firefox Nightly or using the Safe Mode?
Any other details that might help to investigate this further would be appreciated.
|
||
Comment 4•3 years ago
•
|
||
There's a few reasons why the icon may not be stored, though without being able to access the local install, we can only ask you to verify:
- the icon may be served with the "no-store" http header, if so we don't store it, as requested
- the icon may be served in the wrong format or with a wrong content-type
- the request may be blocked because it's mixed-content (http over https) or blocked by an adblocker
You can check the above using the Network panel in Firefox DevTools, find in the list the request for the icon and check its headers and status
- The icon may be set in some particular way (like javascript) after the page is shown, maybe because then it's updated depending on the status of the application. We don't store icons loaded after the pageshow event, because they are very often used to show a state to the user, while the favicon is more a static representation of the site. In this case the fix would be to fix the cockpit code to also provide a default favicon, in addition to the status ones.
The tab shows the icon because not being a permanent store of data, it can ignore all of the above.
|
|
Reporter | |
Comment 5•3 years ago
|
||
From looking at the source, it looks like option 4 is the case here.
|
|
||
Comment 6•3 years ago
|
||
Thank you for checking.
I think this not something we want to fix, mostly because icons set through javascript are most commonly used to show a specific state and are not a good representation of a site/app (or at least, we can't make such assumption). The app should be updated to also provide a static favicon, then it can still overwrite it with js later. I'd thus suggest to report the bug upstream.
Description
•