Closed Bug 327841 Opened 18 years ago Closed 18 years ago

Re-implement a failed favicon cache in the favicon service

Categories

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

defect

Tracking

()

RESOLVED FIXED
Firefox 2 alpha1

People

(Reporter: brettw, Assigned: brettw)

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 1 obsolete file)

The old favicon handling code maintained a cache of favicons that failed to load. This supposedly had a reasonable performance benefit on sites that had invalid or missing favicons.

This should be implemented in the new favicon service. There are some FIXMEs in nsFaviconService.cpp about this.
Priority: -- → P5
Target Milestone: --- → Firefox 2 beta1
Priority: P5 → P1
Target Milestone: Firefox 2 beta1 → Firefox 2 alpha1
Attached patch Patch (obsolete) — Splinter Review
This implements a failed favicon cache that keeps track of favicons that are invalid or otherwise fail to load. It is persisted for the browser session. This saves time when browsing sites that don't have a favicon because we don't try to load the nonexistant favicon for every page.

This also checks for bookmark redirects so that we update the bookmark entry when it redirects to another page that has a favicon. When we set a favicon, we ask the bookmark service if this is the destination of a bookmark (fast because this is based on an in-memory hashtable) and if so, then we also update that bookmarked URI.

This also re-enables caching of data. We keep the favicon data for a day before trying to reload it, which will save a lot of time copying the same data from cache to DB for every pageload.
Attachment #213821 - Flags: review?(bryner)
Comment on attachment 213821 [details] [diff] [review]
Patch

>+  // failed favicon cache
>+  mFailedFavicons.Init(256);

check for out of memory

the 1-day recheck isn't ideal (i'd prefer if we could recheck on first access in a session and get immediate notification from the cache _during_ the session) but in the absence of those notifications this seems ok.
Attachment #213821 - Flags: review?(bryner) → review+
Attachment #213821 - Attachment is obsolete: true
On branch and trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: