Some favicon URLs are not stored or can not be restored

RESOLVED FIXED

Status

()

Firefox for Android
Favicon Handling
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: sebastian, Unassigned)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
For some page URLs we are not storing the favicon URLs correctly or we can't restore them. Our fallback is to guess the favicon URL, but if this is not the one we loaded and cached the favicon from earlier then we won't show one in the UI (The UI loads favicons mostly only from the cache).

I don't know why yet, but this is what I see in the log:

First load of wikipedia.org (clean profile):

> 05-03 20:20:07.040 29151 29151 W SKFAVICON: (Tab) Loading favicon from: https://www.wikipedia.org/static/favicon/wikipedia.ico <<< https://www.wikipedia.org/
> 05-03 20:20:07.041 29151 29393 W SKFAVICON: -----------------------------------------------
> 05-03 20:20:07.041 29151 29393 W SKFAVICON: - https://www.wikipedia.org/
> 05-03 20:20:07.041 29151 29393 W SKFAVICON: -----------------------------------------------
> 05-03 20:20:07.041 29151 29393 W SKFAVICON: > BACKGROUND LOAD FROM: https://www.wikipedia.org/static/favicon/wikipedia.ico
> 05-03 20:20:07.389 29151 29393 W SKFAVICON: (+) Downloaded and now cached: https://www.wikipedia.org/static/favicon/wikipedia.ico
> 05-03 20:20:07.390 29151 29151 W SKFAVICON: Got favicon: https://www.wikipedia.org/static/favicon/wikipedia.ico

* We got the the favicon URL: https://www.wikipedia.org/static/favicon/wikipedia.ico
* We downloaded and cached the favicon.

Now I kill the browser and go to the history panel:

> 05-03 20:20:55.541 30196 30320 W SKFAVICON: -----------------------------------------------
> 05-03 20:20:55.541 30196 30320 W SKFAVICON: - https://www.wikipedia.org/
> 05-03 20:20:55.541 30196 30320 W SKFAVICON: -----------------------------------------------
> 05-03 20:20:55.541 30196 30320 W SKFAVICON: (i) Starting with no favicon URL: https://www.wikipedia.org/
> 05-03 20:20:55.541 30196 30320 W SKFAVICON: (i) NO favicon URL in cache: https://www.wikipedia.org/
> 05-03 20:20:55.556 30196 30320 W SKFAVICON:   (#) Guessing the favicon URL using page URL: https://www.wikipedia.org/
> 05-03 20:20:55.557 30196 30320 W SKFAVICON: (i) Got favicon URL from  getFaviconURLForPageURL(): https://www.wikipedia.org/favicon.ico
> 05-03 20:20:55.557 30196 30320 W SKFAVICON: > BACKGROUND LOAD FROM: https://www.wikipedia.org/favicon.ico
> 05-03 20:20:55.568 30196 30320 W SKFAVICON: (X) Only from local or cancelled: https://www.wikipedia.org/favicon.ico

* We do not have a favicon URL in the cache and there's no tab with the page URL: We guess the default favicon URL: https://www.wikipedia.org/favicon.ico
* We do not have a favicon cached for this URL
* We display the default icon (We only load from cache/local)


This can be reproduced with Wikipedia and a clean profile. However there are other pages with non-default favicon URLs (for example Stackoverflow) where we can and do restore the favicon URL just fine.
(Reporter)

Comment 1

2 years ago
(In reply to Sebastian Kaspari (:sebastian) from comment #0)
> This can be reproduced with Wikipedia and a clean profile. However there are
> other pages with non-default favicon URLs (for example Stackoverflow) where
> we can and do restore the favicon URL just fine.

Every now and then this happens with Stackoverflow and a fresh profile too. It almost looks like some race condition.

Once you are in the error state the history_with_favicons view returns a row but the favicon URL is null.
Blocks: 1268741
(Reporter)

Comment 2

2 years ago
We have two tables (truncated view):

favicons
--------
_id
url
page_url
data

history
-------
_id
url
favicon_id

(The bookmarks table works like the history table in this scenario but i leave it out here)

* When visiting a page we add/update an entry to the history table
* When loading a favicon we add it to the favicons table (or update it). After that we update the favicon_id column of the history table for the page url.


After adding more logs I see that we often load the favicon BEFORE we add the history entry (callback from native code). This means in this situation we never update the favicon_id column. Later we add the history entry and favicon_id remains null because it's already loaded.

Later when we start the app we try to get the favicon URL by looking into the history table (actually a VIEW that joins history and favicons table) but we can't find any url. So we fallback to guessing the favicon URL (http://*/favicon.ico) but there's no matching favicon in our database -> We show the default.

Usually you do not see this problem while browsing as we try to be smart and get the favicon from the Tab object with the same URL while it exists (No database lookups).


Code:

* Updating favicon in database:
  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/db/LocalBrowserDB.java#1272
* Called from LoadFaviconTask:
  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/favicons/LoadFaviconTask.java#113

* Marking Uri as visited:
  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#2782
* Called from native code via GeckoAppShell:
  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/GeckoAppShell.java#1934
(Reporter)

Updated

2 years ago
See Also: → bug 1271594
(Reporter)

Comment 3

2 years ago
This primarily affects fast loading websites (Wikipedia seems to be a good candidate) where we update the history table early and load the favicon late (We won't load it while the website is still loading).

To make things worse: Revisting the site does not fix this because we are serving the icon from the memory cache and do not need to perform a load. Therefore we do not update the database.

Only killing the app and re-visiting the site fixes the issue: Nothing is in any cache. We load the favicon from the web again and there will be a history entry from last time so we definitely update it.
(Reporter)

Updated

2 years ago
See Also: → bug 1271634
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1254465
(Reporter)

Updated

2 years ago
Assignee: s.kaspari → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

a year ago
Depends on: 1290014
(Reporter)

Comment 5

a year ago
Fixed with the new structure in bug 1290014.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.