This is a shame.

Best bet would be a developers.google.com/web/updates post and make sure it's covered in our docs (I'm in the process of moving web-push-book.gauntface.com over to developers.google.com/web) so will add it in there.

Would also be beneficial to give the third parties a heads up as their clients may wonder what is happening.

Regarding the console log, I'm assuming the log will only be visible on Android devices and not visible on desktop? If so, I doubt many developers will see it :(

Presumably all over browsers on Android will be affected by this change?

Cheers,
Matt

peter@ Can you surface this issues by making them appear "not supported" same as:

    if ('actions' in Notification.prototype) {
      // Action buttons are supported.
    } else {
      // Action buttons are NOT supported.
    }

This works for features not supported in both Firefox and Chrome, but in Android O, both sound and vibration are appearing as working in Chrome Canary.

Working with DevRel to prepare a post we can publish as soon as O becomes public is probably the most important thing from a web-developer perspective.  Having a console warning that links to that post is probably helpful as long as it's not too spammy.  Eg. developers likely won't care that much about Android O behavior until there are a non-trivial number of users (at which time it's potentially too late to avoid the damage of course).

Matt's blog post went out here: https://medium.com/dev-channel/changes-to-web-notifications-in-android-o-6055bf8bac90 

Changing this bug to be about adding the feature-detection for silent/vibrate properties on Android O, as described in #4 (and on the blog post).

This is a concern for the experiments we've been doing at the Guardian Mobile lab - for instance, our UK election results coverage last night sent up to 650 alerts (on the same tag) to each user, to create a "live" results table notification. If there was any chance those notifications would make a noise/vibrate we wouldn't want to do that.

What will happen when we push to a tag currently in use? Would that still be consistently silent? (side note: does this also mean the renotify option will fail?)

I know our use-case is pretty weird, but we could still use the API if same-tag notifications were silent *and* we had the ability to make a notification sticky. That way we would know all new alerts are replacing an existing one. I know there are a lot of UI issues with implementing sticky notifications, but just a thought.

Hi Alastair,

Good question, and thanks for raising this use-case.

I tested this, and if you post notifications in quick succession with the same tag and renotify set to false, only the first notification will buzz/make a sound. This is because we call the Android Notification.Builder.setAlertOnlyOnce() method with the opposite of the renotify value, and setAlertOnlyOnce is still respected in Android O - https://developer.android.com/reference/android/app/Notification.Builder.html#setOnlyAlertOnce(boolean) (note this is not deprecated, whereas various other notification builder methods are, in favour of NotificationChannel setters).

O is still in Preview so this is not guaranteed to be the final behaviour, but since this is a common use case for many apps (eg when updating progress notifications), I would be very surprised if this changes.

Note, if a tag isn't set, or the user swipes away the notification, the next notification will buzz. We don't currently support sticky (undismissable) notifications and I haven't heard of any plans to.

- Anita

I currently develop a fire-service alert-paging web application that we use in our local fire department (and some neighboring ones).  It uses web push to notify firefighters of new incidents.  I recently upgraded to Android 8.0, and it's all kinds of messed up.  A huge part of getting the fire notification to be noticed is a distinct vibration pattern (currently three long buzzes).

Under the new Android-8/Chrome (tested on Chrome 60, 61/beta, and 63/canary), the default behavior is "vibrate" turned off, with a quick double buzz for the notification.

When I enable vibration (under "Sites"), I get two long buzzes (but not the three that I have specified from the web push).

I can confirm that in Chrome 63/canary, the site itself appears as an individual notification channel (which is cool), but the vibration pattern still is not the one specified by the web push.  I currently only send one kind of web push notification (new incident that needs your attention), but it would be extremely helpful to be able to send non-critical notifications as well (ones that have a different vibration pattern and sound).

Chrome still does not support the `sound` property (https://notifications.spec.whatwg.org/#dom-notification-sound), but I would hope that whatever solution that you come up with to handle custom vibration patterns (via the `vibrate` property) would apply to the `sound` property when it is supported.