Peter, you handled  Issue 583480 ; do you have an idea what's causing this?

Their chrome.notifications.create() call looks like this:

=========================
chrome.notifications.create(n.id, {
    iconUrl: "../assets/icon.png",
    imageUrl: n.imageUrl,
    message: i.getLocalizedString(n.message),
    priority: n.priority,
    progress: n.progress,
    title: "",
    type: n.type,
    buttons: e
}, ...);
=========================

In short, they pass an empty string as the notification's title. Our code[1] only requires that the title is set, not that it has something sensible.

Web Notifications have the same issue; there's not a whole lot we can realistically do here. This is a deliberate decision on their end. If we require a non-zero-length string, they could use a space. It we trim, they could use some invisible unicode character.

I'm not convinced it's a good idea for us to enter that whack-a-mole game. (Which in itself might break some users.)

Justin, Lucas, WDYT?

[1] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/api/notifications/notifications_api.cc&l=255

I agree, this looks terrible but is obviously the developer's choice.

So does that mean we allow extensions without showing the extension name to make them attributable?

That sounds like a bigger problem to me.

*allow extensions to show notifications without showing the extension name

Yes, but that's orthogonal to showing the notification's title or not.

Web Notifications show the origin of a notification using a toast's "context message", which could be the extension's name when shown by an extension.

http://goroost.com/wp-content/themes/Roost%20v3/new/images/homepage-redesign/engage-screens.png

Extension notifications have control over this context message themselves, and not rarely use it themselves, for example to indicate the e-mail account which just received an e-mail. This hasn't changed since Chrome 28.

We could formally separate the context message and the attribution, but that's a fair bit of work for both UI and Eng. (I'm not opposed to it, but we would have to prioritize accordingly.)

This seems to be working as intent-ended with regards to the title. So let's just close this bug.

If attribution of extensions notifications is a concern let's have a separate bug for that. My initial take is that given its extremely low usage we could simply deprecate giving extensions control of the context message and always use that space for the extension's name. As Peter says anything else would be an important amount of work that the webpush team does not have the cycles for. We are also running out of notification space, especially in native notifications, so it is not clear where the attribution would go otherwise.

In any case let's discuss it in a separate bug.

https://bugs.chromium.org/p/chromium/issues/detail?id=593694 for the attribution bug

miguelg@: Shunting this into 593694 sounds good to me. Thanks for filing it!

Security>UX component is deprecated in favor of the Team-Security-UX label