Closed
Bug 615602
Opened 14 years ago
Closed 7 years ago
Add method to get the best available icon for a domain
Categories
(Toolkit :: Places, defect, P3)
Toolkit
Places
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
status2.0 | --- | wontfix |
People
(Reporter: kairo, Unassigned)
References
Details
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•14 years ago
|
||
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
Reporter | ||
Comment 2•14 years ago
|
||
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•14 years ago
|
||
yes, we also need it for grouped by site views, indeed I thought this was already filed.
Comment 4•14 years ago
|
||
(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]
Reporter | ||
Comment 5•14 years ago
|
||
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.)
Updated•8 years ago
|
Depends on: PlacesHiresFavicons
Updated•8 years ago
|
Priority: -- → P3
Comment 6•8 years ago
|
||
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•7 years ago
|
||
As I said, this is partially covered by the page-icon protocol, further bugs should be created as we see need.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•