The "new mail" notifications two icons after the landing of bug 852648, see attached screenshot. OS X version: 10.9

The OS automatically includes the application's icon in the alert. Looks like Thunderbird is including it again as the optional image. Thunderbird could opt out of including its own icon on OS X <= 10.8, or we could add an attribute to the API which says whether or not the OS includes the application icon automatically.

Coded up my API suggestion, not sure if we want this or for Thunderbird to hard-code by OS.

(In reply to Josh Aas (Mozilla Corporation) from comment #2) > Coded up my API suggestion, not sure if we want this or for Thunderbird to > hard-code by OS. Why don't you just handle that in the notification provider itself?

(In reply to Florian Bender from comment #3) > Why don't you just handle that in the notification provider itself? I don't know what you mean.

(In reply to Josh Aas (Mozilla Corporation) from comment #4) > I don't know what you mean. So, AFAIU, the NC support was added as a notification provider, replacing the XUL alerts on supported platforms. (In reply to Josh Aas (Mozilla Corporation) from comment #1) > Thunderbird could opt out of including its own icon on OS X <= 10.8, or we > could add an attribute to the API which says whether or not the OS includes > the application icon automatically. The notification provider for NC should detect whether a notification comes from web content (which provides custom icons), or chrome which should only display the application icon and no custom icon. I assume this can simply be fixed by ignoring any notification icon that resides in any chrome package (identified by the chrome:// and possibly resource:// URI). (This may exclude addons from providing notifications with a custom image however I think this is only a minor annyoance rather than a bug.)

(In reply to Florian Bender from comment #5) > (In reply to Josh Aas (Mozilla Corporation) from comment #4) > > I don't know what you mean. > > (This may exclude addons from providing notifications with a custom image > however I think this is only a minor annyoance rather than a bug.) I disagree. Chrome code should be able to specify whatever icon they want. Things like Social API and add-ons would use this. I think the main bug is that Thunderbird should use an icon other than the application icon e.g. an envelope to indicate new mail and a calendar icon for event reminders.

(In reply to Matthew N. [:MattN] from comment #6) > I disagree. Chrome code should be able to specify whatever icon they want. > Things like Social API and add-ons would use this. I think the main bug is > that Thunderbird should use an icon other than the application icon e.g. an > envelope to indicate new mail and a calendar icon for event reminders. Oh, I like that solution better! Then again, this would impact platforms with XUL notifications, because they only display one icon. So for notifications like a pending update, either a special icon needs to be displayed (not the Thunderbird icon) or the generic icon is shown (by not specifying an icon URI). This can only be mitigated by Josh's proposal (so a developer needs to add an if-clause everywhere he wants to use the brand icon in a notification), or a way for detecting if a notification tries to display the brand icon. I assume that there is no practical way to auto-detect the brand icon by analyzing its URI (because each product has a different brand icon URI, and it may not even be in the same directory). So another option is for the notification to specify that it references the brand icon, e.g. (using the WebNotification API with a vendor prefix because I don't know the Gecko API, though this should definitely not be exposed to content): new Notification("Notification", { icon: "chrome://thunderbird/brand/icon.png", mozUsesBrandIcon: true }); That way the notification service implementation can choose to ignore the icon if the aforementioned option is set. Actually, this can be simplified to just: new Notification("Notification", { mozUseBrandIcon: true }); … which automagically uses the brand icon (i.e. sets "icon" to the brand icon URI thus ignoring the "icon" option). In all other cases, the generic notification icon (megaphone) is used unless a valid icon resource is defined (which is currently only used in XUL notifications, see Bug 948115). I find that to be a cleaner solution than a new API.

Another option would be to default to chrome://branding/content/icon64.png (or similar) for the notification icon in XUL notifications if the origin has chrome privileges, otherwise use the loudspeaker. This would be like how NC defaults to the application icon if none is specified. I believe those brand URIs are used on most gecko applications.

Bug 1271467 fixed the two icons issue. But thanks for the patch anyway.