Closed Bug 394987 Opened 17 years ago Closed 16 years ago

for history UI, use site icon instead of folder icon when doing view by site (or view by date and site)

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 323933

People

(Reporter: moco, Unassigned)

References

Details

for the history sidebar, use site favicon instead of folder icon when doing view by site (or view by date and site) this suggestion comes from faaborg.
Flags: blocking-firefox3?
Also effects the places organizer
Blocks: 393506, 393514
Summary: for the history sidebar, use site favicon instead of folder icon when doing view by site (or view by date and site) → for the history, use site favicon instead of folder icon when doing view by site (or view by date and site)
Whiteboard: [places-ui]
Summary: for the history, use site favicon instead of folder icon when doing view by site (or view by date and site) → for history UI, use site favicon instead of folder icon when doing view by site (or view by date and site)
We also need a generic site icon in cases where there is no favicon
Assignee: nobody → mano
Target Milestone: --- → Firefox 3 M8
Target Milestone: Firefox 3 M8 → Firefox 3 M9
(In reply to comment #2) > We also need a generic site icon in cases where there is no favicon > Of course; why not the same generic icon as the one displayed (in whatever theme is current) on the tab and (if we still do) in the location bar when neither the site nor the page defines a favicon? (Principle of least surprise)
That icon represents a page, not a site. We were thinking about maybe stacking 3 pages together or something for the site icon, but we are still in the process of brainstorming.
Morphing this slightly - mconnor points out that we might want to consider always using a generic site icon as it's possible (though admittedly not likely) that a single site could have multiple favicons. Not sure we want to care deeply about that, but we should consider it.
Flags: blocking-firefox3? → blocking-firefox3-
Summary: for history UI, use site favicon instead of folder icon when doing view by site (or view by date and site) → for history UI, use site icon instead of folder icon when doing view by site (or view by date and site)
Whiteboard: [places-ui] → [places-ui][wanted-firefox3]
(In reply to comment #5) > Morphing this slightly - mconnor points out that we might want to consider > always using a generic site icon as it's possible (though admittedly not > likely) that a single site could have multiple favicons. Not sure we want to > care deeply about that, but we should consider it. > IIUC, each site can only have at most one site-wide icon -- favicon.ico in the site's root directory (e.g., as the traditional example goes, www.microsoft.com/favicon.ico ) This site-wide icon may be overridden for individual pages by <link> tags, which point then to "page icons" which aren't "site icons" since they must be specified individually by every page using them. If a site has _no_ /favicon.ico, we should of course fall back on some generic icon (which shall be) defined by the current theme (i.e., by the "default" theme installed with the browser, unless the user has chosen another one).
>we might want to consider >always using a generic site icon as it's possible (though admittedly not >likely) that a single site could have multiple favicons. That's designing for a boundary case. I believe favicons in history will noticeably improve usability, because many of them are very recognizable, and even the unrecognizable ones form patterns (all morning on a certain site, switching between two sites, etc.) If a site has multiple page favicons (which I think we should fall back to if there is no favicon.ico), we can just use the first one we encounter, or maybe switch back to the generic icon if we encounter different ones and want to be fancy. But we shouldn't kill the entire feature just because of a rare possibility of confusion. >If a site has _no_ /favicon.ico, we should of course fall back on some generic >icon Yes, but we need a second generic icon that represents a site. The current generic favicon is designed to represent a single Web page.
I am not sure the argument in comment 6 and comment 7 is correct. The work to find the favicons has already been done for the entries inside the folder. We definitely don't want to start random requests for /favicon.ico again. More likely the code will have to look at the places database and decide on the icon from the icons of the individual entries; I have just viewed my history by site and in most cases the icon with the largest count is the one I would expect to be shown (one exception is my own site which does have different icons for http://www.bristol.ac.uk/... and http://www.bristol.ac.uk/is/...). I would expect to do something like: o If there is only one page in the folder use its icon o If all pages in folder have same icon then use that. o For site.example.com, if http://site.example.com/ is in the database then use its icon (possibly including other common home pages index.htm/php/shtml/html) o If there is a majority count for an icon for all entries in the folder (that have an icon) then use that. I would expect that 'date and site' would use the 'site' counts and not the subset. I use the odd combination of siteicons true and favicons false (plus HashColouredTabs+ to give unique icons to sites without a declared siteicon) so my history is not typical, so it may be interesting to see if other histories show similar patterns.
>More likely the code will have to look at the places database and decide on the >icon from the icons of the individual entries Yeah, we should store the site favicon locally in places. >o If there is only one page in the folder use its icon >o If all pages in folder have same icon then use that. >o For site.example.com, if http://site.example.com/ is in the database then use >its icon (possibly including other common home pages index.htm/php/shtml/html) >o If there is a majority count for an icon for all entries in the folder (that have an icon) then use that. That sounds like a great approach.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Assignee: mano → nobody
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Flags: wanted-firefox3+
Whiteboard: [places-ui][wanted-firefox3] → [places-ui]
Target Milestone: Firefox 3 beta3 → ---
Dietrich: I have a generic site icon listed in the icon inventory. Do you want me to remove it from the list of needed icons, or is there any chance that we could use that icon instead of folder icons in the history sidebar?
Alex, I think we should punt on this. Its a nice to have at best, and its just yet another thing we really don't have time to sort out right now (let alone more churn for themers post-b4).
>I think we should punt on this. Ok, setting the icon in the inventory to not needed.
This bug seems to get lost in the 3.0 dev cycle. Something for Firefox 3.1?
Flags: wanted-firefox3.1?
Yeah, I'm adding this to the inventory of Firefox 3.1 icons to produce.
This probably depends on bug 323933 - if not a duplicate.
indeed i'm duping, Alex please take a look at the other bug and post eventually missing informations/icons.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Whiteboard: [places-ui]
Flags: wanted-firefox3.5?
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.