Created attachment 618424 [details] folder pane enhanced with email domain favicon User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/20120425 Firefox/15.0a1 Build ID: 20120425040205 Steps to reproduce: If you use Smart Folder view in the folder pane and you don't have every type collapsed you see the icon several times. This was also in focus in Bug 490227. But instead of just hiding the icon, I suggest displaying the favicon of the email accounts first level domain (sometimes there is a second level, which doesn't exist in most cases) instead of the folder type icon. This would make it easier to identify the folders of diffrent mail accounts. This would also make sense for the top account nodes. I attached a mockup showing how this could look.
This is not the Theme component and actually more complicated than one may assume given that the favicons for each provider would have to be obtained somehow (and there certainly will be many providers which don't have one, in which case the default folder icon). So, this should be interesting implementation-wise unless there is some standard way to get a provider's favicon from the domain alone.
Severity: normal → enhancement
Component: Theme → Folder and Message Lists
QA Contact: theme → folders-message-lists
Version: 11 → Trunk
It could be sane to: 1. Take the server URL and check for a favicon: (e.g. imap.foo.test/favicon.ico or pop3.bar.local/favicon.ico). 2. If that 404s, remove the first sub-domain and repeat step 1. 3. Repeat step 2 until a 200 is returned or a tld is reached. I think this would be a pretty sweet feature. Bug 745301 might be helpful in implementation.
Alta88, would you like to implement this too for mail folders? It seems you have done all the infrastructure, it "just" needs to be used also for mail servers. Hopefully fetching the icons does not stall TB until they are fetched (if even possible). There may be people on slow links (but fine for email) or even behind firewalls so fething may not even succeed. This should be taken into account.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
It would probably take a few lines of code to implement the feeds methods to servers, which even go so far as to xhr and parse a domain's web page, since many sites don't use the /favicon.ico location. This would be 'good enough'. However, the implementation would be much better if 1) favicons were derived from Places infrastructure; the current methods use an old non storage Places api call which fails in callback, requiring hacky timed retries until a favicon is resolved one way or another. 2) favicons, once resolved, are cached on the folder tree view instance; this is fine in most use cases, but when tearing down the tree for smartfolder view changes results in suboptimal reloading of all icons; worse is when new messages cause a teardown (unread iirc). This should be revisited, ie whether the caching should be in a static session location, whether full Places infra should be implemented, or whether just calling the old api to get the favicon out of memory is sufficient (getImageSrc on each mouseover etc, which is why they were specially cached for nsITreeView).
You need to log in before you can comment on or make changes to this bug.