Forgot to add that this feature in chrome://flags must be enabled:

[ ] Enable native notifications. Mac
    Enable support for using the native notification toasts and notification center on platforms where these are available. #enable-native-notifications

[mac bug triage]

+rsesek from owner's file for chrome/browser/notifications and
+miguelg from chrome/browser/notifications/notification_platform_bridge_mac.mm git blame

Would either of you be the right one to look at this? Is this intentional? Thanks!

This was intentional, we cannot reliably elide domains that are too long so we decided to go with ETLD+1 instead.

I am keeping this open however to explore some mitigations since it is clearly unfortunate for notification aggregators and other cases where an intermediary is not fully recognised as an etld but is in practice acting as such.

We're worried the user experience is going to suffer without some kind of subdomain inclusion. Take the example of a user wanting to unsubscribe from a notification they just received:

1. User receives unwanted notification that shows 'onesignal.com' as the source

2. User clicks 'settings' button on notification 

3. User is taken to Chrome Settings page, which lists all sites blocked and allowed

4. If user has turned on notifications for more than one 'onesignal.com' domain, user will be unable to determine which domain sent the notification and thus which one to disable.

MacOS Chrome users receive millions of web push notifications from our aggregator domain daily, so we're worried the problem will have a significant effect if they lose the ability to tell who its coming from. We also don't see the situation of clients changing their approach in the near future, as the aggregator domain solution we have remains in high demand.

One idea for how to mitigate this is to truncate the beginning of the string rather than the end:

E.g. reallylongsubdomain.aggregator.com  becomes  ...ubdomain.aggregator.com

This solution preserves the display of the domain so there aren't security issues, and it leaves open the possibility of recognition on the part of the user. 

The text area character count in MacOS Native notifications range from 16 (just m's) to 36+, realistically at least 24+. That's enough to fit a significant portion of domains without truncation. With the above fix, the upside would be that in likely the majority of cases users would be less confused, and the downside would be no worse than the current solution (just a few extra ellipses sometimes). It's not the most elegant but it likely results in the least user confusion.

cheers

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8c70962f2be02fc57fc5bea12c7f7052605709ce

commit 8c70962f2be02fc57fc5bea12c7f7052605709ce
Author: miguelg <miguelg@chromium.org>
Date: Mon May 08 10:43:27 2017

Only resort to etl+1 when the full domain does not fit.

Mac native notifications have a somewhat constrained space for the origin
Unlike chrome notifications it's harder to decide when to elide so instead
we either show the full domain (if it fits in the very conservative limit
we know works) or resort to etld+1 when it doesn't.

BUG= 717725 

Review-Url: https://codereview.chromium.org/2861133003
Cr-Commit-Position: refs/heads/master@{#469953}

[modify] https://crrev.com/8c70962f2be02fc57fc5bea12c7f7052605709ce/chrome/browser/notifications/notification_platform_bridge_mac.mm
[modify] https://crrev.com/8c70962f2be02fc57fc5bea12c7f7052605709ce/chrome/browser/notifications/notification_platform_bridge_mac_unittest.mm

Thanks for your attention on this. See that the patch changes the behavior so that the full domain is used if it is 21 or fewer characters, otherwise it will use the etl+1.

Out of our clients, approximately 50% have a domain+subdomain that exceeds this 21 character limit.

That's already a good improvement. It's unfortunate that we have so little space here.

Since you have a large amount of subdomains for your clients, consider submitting a request to the public suffix list. This is the list that we use to determine the eTLD. I'm not familiar with the requirements though, I'm afraid.

https://publicsuffix.org/

Thanks Peter. We'll take a look at publicsuffix.

This 50% is 40,000 websites and 50 million subscribers, so this will have a very widespread impact. It would be helpful if you could look into alternate options or wait until we successfully get into your suffix list before going live with this. 

I don't think that it's a good idea to special case your domain given that other parties will likely run into the same issue. We might be able to stretch the limit by a few characters, but that'll require some back-and-forth.

Since you have a list, would it be possible for you to share character counts at which we reach 75%, 90% and 95% coverage?

Yes:

Total using subdomain: 50123
Total domain length is 27 characters or less: 73%
31 or less: 90%
35 or less: 96%

We've submitted a pull request for onesignal.com to be added to the Public Suffix List: https://github.com/publicsuffix/list/pull/450.

We ended up canceling our pull request for publicsuffix due to concerns about how this would affect cookies being set by some libraries we use. Unfortunately that's probably not a good path forward for us or other aggregators that will be affected by this change.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7bf282aee6c77b7142d25900d5fd42c822a6d24d

commit 7bf282aee6c77b7142d25900d5fd42c822a6d24d
Author: miguelg <miguelg@chromium.org>
Date: Wed May 10 11:17:22 2017

Relax the character limits before resorting to eTLD+1

BUG= 717725 

Review-Url: https://codereview.chromium.org/2865323002
Cr-Commit-Position: refs/heads/master@{#470527}

[modify] https://crrev.com/7bf282aee6c77b7142d25900d5fd42c822a6d24d/chrome/browser/notifications/notification_platform_bridge_mac.mm
[modify] https://crrev.com/7bf282aee6c77b7142d25900d5fd42c822a6d24d/chrome/browser/notifications/notification_platform_bridge_mac_unittest.mm

Ok, we've experimented a bit more and raised the limits somewhat so more of your notifications should make the threshold now. At this point there is not much else we can do I'm afraid.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/20130882054a5b215f79d01c9ff73958780ad56b

commit 20130882054a5b215f79d01c9ff73958780ad56b
Author: miguelg <miguelg@chromium.org>
Date: Thu May 11 08:01:30 2017

Remove the unnecessary id_ member from the extension delegate

This is a small clean up in preparation for removing the delegates when
using extensions and non persistent notifications.

BUG= 717725 

Review-Url: https://codereview.chromium.org/2870933002
Cr-Commit-Position: refs/heads/master@{#470866}

[modify] https://crrev.com/20130882054a5b215f79d01c9ff73958780ad56b/chrome/browser/extensions/api/notifications/notifications_api.cc

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e1dc2eaca46b9dd95beade54ea404652648e07fd

commit e1dc2eaca46b9dd95beade54ea404652648e07fd
Author: Miguel Garcia <miguelg@chromium.org>
Date: Fri May 12 12:16:10 2017

Only resort to etl+1 when the full domain does not fit.

Mac native notifications have a somewhat constrained space for the origin
Unlike chrome notifications it's harder to decide when to elide so instead
we either show the full domain (if it fits in the very conservative limit
we know works) or resort to etld+1 when it doesn't.

BUG= 717725 

Review-Url: https://codereview.chromium.org/2861133003
Cr-Commit-Position: refs/heads/master@{#469953}
(cherry picked from commit 8c70962f2be02fc57fc5bea12c7f7052605709ce)

Review-Url: https://codereview.chromium.org/2882663002 .
Cr-Commit-Position: refs/branch-heads/3071@{#527}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/e1dc2eaca46b9dd95beade54ea404652648e07fd/chrome/browser/notifications/notification_platform_bridge_mac.mm
[modify] https://crrev.com/e1dc2eaca46b9dd95beade54ea404652648e07fd/chrome/browser/notifications/notification_platform_bridge_mac_unittest.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d10c4af6902e075e15de2b3348f9b1d35646cb9f

commit d10c4af6902e075e15de2b3348f9b1d35646cb9f
Author: Miguel Garcia <miguelg@chromium.org>
Date: Fri May 12 12:21:33 2017

Relax the character limits before resorting to eTLD+1

BUG= 717725 

Review-Url: https://codereview.chromium.org/2865323002
Cr-Commit-Position: refs/heads/master@{#470527}
(cherry picked from commit 7bf282aee6c77b7142d25900d5fd42c822a6d24d)

Review-Url: https://codereview.chromium.org/2877053002 .
Cr-Commit-Position: refs/branch-heads/3071@{#528}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/d10c4af6902e075e15de2b3348f9b1d35646cb9f/chrome/browser/notifications/notification_platform_bridge_mac.mm
[modify] https://crrev.com/d10c4af6902e075e15de2b3348f9b1d35646cb9f/chrome/browser/notifications/notification_platform_bridge_mac_unittest.mm

I think this is as much as we can do for M59 we will revisit this in future milestones to see if we can elide the origin (like we do in all other platforms) in a sensible manner.

Rechecked this on chrome version 59.0.3071.61 on MAC 10.12.4 using test URL:http://notify.tech,  attached is a screen shot for the same. Is this intended.

@miguelg: Request you to please check and confirm.

Thanks.! 

Deleted: Notification.png 85.1 KB

	Notification.png 85.1 KB View Download

Confirmed.

Thanks for the update, adding TE-Verified labels.