User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 I would like Firefox to store favicons with more than 16x16 pixels. The 16x16 version can still be kept in places.sqlite, but a higher, perhaps even full resolution version should be kept somewhere. This is a good idea for several reasons: 1. Better Cloud - gives Mozilla Prism a potentially clearer default icon to display, as well as for desktop shortcuts (see https://bugzilla.mozilla.org/show_bug.cgi?id=110894 for parity with gchrome and safari). 2. Better Extensions - more recognizable representation of a website than a thumbnail in about:tab as well as for opera speed-dial type extensions. 3. Better Mobile / Convergence - useful for Fennec shorcuts, just as the iPhone has implemented a 57x57 apple-touch-icon.png for a higher quality representation of a website. 4. Better Polish - gives users an opportunity to have large toolbar icons without blurriness. 5. Ditto - opportunity to create a more beautiful bookmark properties dialog that includes an icon (just like shortcuts/aliases do on the desktop "properties" or "Get Info" dialogs). Although most sites don't use large icons now, they will if Firefox puts it into the browser (same rationale for including Geolocation in 3.5). Some formats also support multiple resolutions in a single file (e.g. .ico). Reproducible: Always

It already appears to store the favicon at full size (unless the image itself exceeds a certain number of bytes I think). What makes you think it doesn't?

In places.sqlite, I believe the icon is always resampled to 16x16 and shrinks to less than 1kb. So any retrieved icons are this size.

You believe or have evidence? My tests show that the icon is stored at full size.

I haven't done any tests, but just reading the source it looks like both of you are right. An image that is larger than 1KB is "optimized" -- it's scaled to 16x16. If optimization fails but the image is still less than 10KB, or if the image was under 1KB to begin with, the image is left unscaled: nsFaviconService::SetFaviconData http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/src/nsFaviconService.cpp#692 Actually you can store arbitrary data by using annotations, which may be associated with a place or with a bookmark. An interesting case in point is bug 489173. Only chrome code can do that, though, so it's not quite what you're asking for. I think your argument is compelling and worth considering.

I submitted a related security Bug 442731 earlier - GIF images were not being resampled at all - ("I believe" was just my trying to be polite and admit I could be wrong). There is a 1kb limit on icons in places.sqlite, and all the icons are 16x16. Perhaps the icons you are observing were gif icons set before this fix went out?

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

My understanding is that this bug will be about storage of large icons so I'm changing the summary so it doesn't get confused with updating the Places UI to use higher resolution icons.

The hi-res icons in Places project is complete, remaining bugs will go through the usual triage and backlog process, we don't need anymore this meta bug to track the project.