hao1300@ Thanks for the issue.

Request you to provide a sample extension where this issue can be reproduced, which will help in further triaging.

Thanks..

I have attached a very simple chrome extension to demonstrate this bug.

Deleted: notification_bug.zip 3.8 KB

notification_bug.zip 3.8 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

hao1300@ Thanks for the update.

Able to reproduce the issue on Windows 10 on reported version 68.0.3440.106 and on latest canary 70.0.3529.0 with the extension provided in comment #3 and enabling the flag #enable-native-notifications. 
Attached is the screen cast for reference.

Note: Issue is not observed on Mac OS and Ubuntu 14.04.

This issue is seen from M-67(67.0.3369.0) from introduction of "native notifications" flag.
hence this is a Non-Regression issue and marking it as Untriaged for further updates from Dev.

Thanks!

Deleted: 875651.mp4 881 KB

	875651.mp4 881 KB View Download

Finnur, could you take a look please?

First of all, thanks for the extension, hao1300! Makes this super easy to repro.

Preliminary results...

Every call to notification.update results in a corresponding call to NotificationPlatformBridgeWinImpl::Display with the right message ("text 1", "text 2", etc). We call Show() on the Notification interface, which registers each update with the Action Center.

After that, it gets a bit weird. If I just let it run, I see that the Action Center puts up the initial message in a popup, and then updates ONLY ONCE the message in that popup (Test -> Text 1). But weirdly only a total of 7 updates reaches the Display() and no error is output anywhere (C++ or JS).

But if I leave the Action Center open while these updates are being sent, then no popup appears on-screen, but I see the updates pile up there, and everything seems to work correctly (each update is shown in order and it continues until I close the Action Center). 

I'm kind of scratching my head here... :) I can't see anything wrong on our end...

For posterity: we set the same Group and Tag string to each notification we request be displayed. The XML looks the same each time, except in two locations below, where it says [**variable**]:

<?xml version="1.0"?>
<toast launch="0|2|Default|0|chrome-extension://pllemkpnnppnbblhjfldpfhmeipdeofh/|pllemkpnnppnbblhjfldpfhmeipdeofh-8fbcaeee-5c6a-42d6-9a2d-9a3d95dbbbfa" displayTimestamp="2018-08-27T15:02:15Z">
 <visual>
  <binding template="ToastGeneric">
   <text>Notification bug</text>
   <text>text: [**variable**]</text>
   <image placement="appLogoOverride" src="[**variable**]" hint-crop="none"/>
  </binding>
 </visual>
 <actions>
  <action content="Go to Chromium notification settings" placement="contextMenu" activationType="foreground" arguments="2|2|Default|0|chrome-extension://pllemkpnnppnbblhjfldpfhmeipdeofh/|pllemkpnnppnbblhjfldpfhmeipdeofh-8fbcaeee-5c6a-42d6-9a2d-9a3d95dbbbfa"/>
 </actions>
</toast>

... with, of course, the exception of [variable] above.

Is it possible to fix this bug? Or at least postpone enabling the flag on Windows until it is fixed?

*** UI Mass Triage ***

Closing, since there is no update since the past few weeks.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue.

This bug still exists today. Can someone look into it?

I reached out to Microsoft in November about this issue, but haven't heard back. It looks to me like the issue is on their side and they had someone looking into it, but I don't anticipate any follow-up work being required from our side...

Would it be possible to disable native notifications on Windows by default? Or provide some alternatives in which chrome.notifications.update actually works properly? The way it is now, chrome.notifications.update API just doesn't work the way it used to (or the way anyone would expect it to work).