Open Bug 1948804 Opened 1 month ago Updated 1 month ago

wrong favicon in bookmarks, new tab page and history

Categories

(Firefox :: Bookmarks & History, defect, P3)

Firefox 135
defect

Tracking

()

People

(Reporter: seb.ireland, Unassigned)

References

Details

(Keywords: papercut, Whiteboard: [sng][places-papercut])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Normal usage and browsing over many years

Actual results:

I have :

  1. a huge number of bookmarks that grew up for almost 2 decades probably,
  2. 3x8 shortcuts on my "new tab" page
  3. browsing history

In these 3 cases, Firefox will mix up some favicons for some websites and I cannot fix this by providing the right url in the new tab page for example.

It seems to be the case with URLs that have changed and are being redirected after it was bookmarked.
Example : https://advance.paymium.com/#/en/Paymium/eur/trading
is now redirected to :
https://account.paymium.com/trade/BTC/EUR#/en/Paymium/eur/trading

If I bookmark the second URL it gets the proper favicon from the website, but the old URL, in my old bookmarks get another icon.

It happens to be a favicon of one of my own website (online, on a regular web server at a provider with a regular https URL) but on other cases, in my History (today's history) for example : the old blue bird Twitter icon on many Facebook URLs. But not all of them. It seems to behave by batches : in my history I will see 30 URLs with the wrong icon, and then the next dozen with the proper icon. It is not randomly distributed, it is series of them. But I also have the case where I only visited 3 Facebook page, and one had the wrong icon.

The number of websites for which this happens is small. There is paymium.com, facebook.com

This is not a critical bug, but I am surprised that this bug has been existing for many years and never fixed.

There is some kind of pattern :

  • deprecated URLs (redirected on their server but not updated on my bookmarks)
  • deprecated icons (still in my cache ?)

In the History : The Twitter.com URLs all have the "X" icon (but sometimes white on black, sometimes brown on black) none of them has the old blue bird twitter icon
In my bookmarks : the three types of twitter icons appear

Expected results:

each link should have the favicon of its website

PS : I would like to add that Facebook.com URLs in my history are from today, many months after the twitter blue bird icon has been deprecated by twitter, and the URLs here are not deprecated nor redirected in these instances. They bring exactly to the URL that has been recorded in my History.

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.

Component: Untriaged → Bookmarks & History

It sounds like the database contains some icons with bogus association/data, and that keeps being applied. This is something I've seen happening in old profiles, but it's really hard to debug as it may be something that happened years ago.
Icons remain in cache until the page they were associated with is reloaded, if that page doesn't exist anymore, or starts redirecting, it's likely they won't be expired.
For bookmarks it's sufficient to update the url to a new one to fix the situation, that won't help history though.

Expiring icons that were not updated from a long time is an interesting thing to evaluate, looking at my database there's ~400 icons that have not been updated in 2 years, and they have ~5000 links to pages.
There's a good chance to expire many of these and free up some space.

I was running this query locally:

SELECT h.url, i.icon_url,
  datetime(ip.expire_ms / 1000, 'unixepoch') AS expire_link,
  datetime(i.expire_ms / 1000, 'unixepoch') AS expire_icon,
  datetime(last_visit_date / 1000000, 'unixepoch') AS last_visit_date
FROM moz_icons i
JOIN moz_icons_to_pages ip ON ip.icon_id = i.id
JOIN moz_pages_w_icons p ON ip.page_id = p.id
JOIN moz_places h ON h.url_hash = p.page_url_hash
WHERE i.expire_ms BETWEEN 1 AND 1676711274085
  AND ip.expire_ms BETWEEN 1 AND 1676711274085
  AND root <> 1
AND h.foreign_count == 0

This doesn't necessarily mean all of these must be expired, but it's a quite large number of entries.
Many of these pages have a very recent last visit date, but some relations and icons are 2 years old.
I was wondering if these pages are redirects, though only 11 out of 2099 are considered redirects, according to history. I verified that some of the pages are indeed not redirects.

We are supposed to expire relations according to https://searchfox.org/mozilla-central/rev/a80b3969c6d78ac5ba2552a5bce5e5c7a74f3a9b/toolkit/components/places/FaviconHelpers.cpp#671-673 and that query looks right, so maybe it's not running at all?

The only way forward at this point is to go through a debugger session.

Flags: needinfo?(mak)

Afaict the code is correct, or at least I couldn't find obvious mistakes, and revisiting some of these pages properly cleans up old associations, verified in the debugger.

The problem at hand is that icons for some pages just become stale, because those pages:

  1. were not visited anymore
  2. started not having a favicon anymore
  3. started forwarding/redirecting somewhere else

We accept icons to remain as far as the page is in history, though if page revisits cannot expire old icons, they will just continue piling up.
We can make an heuristic based on the difference between last_visit_date and moz_icons_to_pages.expire_ms, though we cannot assume a visit will surely cause an icons fetch; visits may be inserted by Sync, and in that case there was no actual icons fetch.

To reduce the dataloss risk, we could evalute expiring icon associations where that difference is large enough, if there was no network fetch in such large timeframe, the user is less likely to be interested in that page. I have noticed many mis-associations in this group (like a Mozilla icon from 2022 associated to Seasonic website visited in 2025).
How large should the timediff be? We could probably start with 1 year, so having last network fetch 1 year before the most recent visit.

This query would expire about 15 thousands associations in my profile:

SELECT ip.page_id, ip.icon_id, datetime(ip.expire_ms / 1000, 'unixepoch')
FROM moz_icons_to_pages ip
JOIN moz_pages_w_icons pi ON pi.id = ip.page_id
JOIN moz_places h ON pi.page_url_hash = h.url_hash
WHERE last_visit_date / 1000 - ip.expire_ms > (365*24*60*60*1000)
AND  foreign_count = 0
ORDER BY 3
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mak)
Keywords: papercut
Priority: -- → P3
Whiteboard: [sng][places-papercut]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: