615602 - Add method to get the best available icon for a domain

Status: RESOLVED WORKSFORME

(Toolkit :: Places, defect, P3)

Description

[Robert Kaiser]

In cases like bug 573176 or bug 588422, we end up needing an icon to go with a domain name and needing to figure out some algorithm to get the best available icon for that domain.

It would be good to have a way to request this via a method in probably the favicon service itself instead of manually fiddling with places tables.

This could also be used e.g. for "website" containers in the history view (not sure if Firefox has that, but SeaMonkey does for sure, given you apply a grouping that requires them).

Comment 1

[Shawn Wilsher :sdwilsh]

I regret to say that given the amount of work we have on the table for 2.0, we won't take this.  This is a good idea though, and we'd be happy to look at it post-2.0

Comment 2

[Robert Kaiser]

Shawn, sure, I wasn't meaning that this was needed for 2.0, just wanted to make sure it's filed as it would be helpful to have in the future.

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

yes, we also need it for grouped by site views, indeed I thought this was already filed.

Comment 4

[John P Baker]

(In reply to comment #3)
> yes, we also need it for grouped by site views, indeed I thought this was
> already filed.

This is bug 323933.

I gave this some thought for bug 394987 bug gave up as there were too many edge cases; The only cases where it made sense were
1) When all pages for a site had the same icon
2) When we had an icon for the home page

In all other cases it was too easy to think of cases where a wrong or misleading icon would be shown.

For preferences there is a particularly bad case
3) when there are no visits in history for a particular site; For this case you would probably need to store extra entries in the favicon database whenever a preference (eg cookie) was set (and possibly a new table mapping _site_ to icon).

[Note there are many relevant comments in bug 394987 even though this marked as a duplicate of bug 323933]

Comment 5

[Robert Kaiser]

We can always fall back to not returning an icon if we don't have a good one, in which case the consumer should use some reasonable generic default (just like we do for tab icons, etc.)

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

It should currently be possible to use "page-icon:http://www.mozilla.org/" to get an icon for the domain, if one is available, or the same through getFaviconURLForPage or getFaviconDataForPage.
That will work only if we stored the root domain icon (domain/favicon.ico) for some of the contained pages, that is something we plan to do for every page (probably in bug 1352459).
This is not the same as always trying to return an icon, but should match better.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

As I said, this is partially covered by the page-icon protocol, further bugs should be created as we see need.