Replacing a notification keps the old one in notifications list indefinitely
Reported by
teodorma...@gmail.com,
Aug 7 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce the problem: As per specs (https://notifications.spec.whatwg.org/#replacing-a-notification), when an old notification is replaced by a new one (when both notifications have same, non-empty tag), the old notification should be removed from the list of notifications and the new one placed in its spot. However this is not happening. To reproduce it (in the service worker context): self.registration.showNotification('A', { tag: 'abc' }) .then(() => self.registration.getNotifications({ tag: 'abc' })) .then(notificationsList => { console.log(notificationsList); // [ NotificationA ] return self.registration.showNotification('B', { tag: 'abc' }); }) .then(() => self.registration.getNotifications({ tag: 'abc' })) .then(notificationsList => { console.log(notificationsList); // [ NotificationB, NotificationA ] return self.registration.showNotification('C', { tag: 'abc' }); }) .then(() => self.registration.getNotifications({ tag: 'abc' })) .then(notificationsList => { console.log(notificationsList); // [ NotificationC, NotificationB, NotificationA ] }) What is the expected behavior? The result of self.registration.getNotifications({ tag: 'abc' }) should only contain the latest Notification, which was to replace the old one. What went wrong? To "prevent" this behavior in code, before calling the self.registration.showNotification(), you need to explicitly walk through the notificationsList for that tag and call .close() on every Notification object. The Notification is only ever removed from the notifications list when the person explicitly closes the notification by swiping it away or clicking [x] button on the notification (in that case, the .close() is called implicitly), or when the code itself calls .close() on a Notification. Did this work before? No Chrome version: 51.0.2704.103 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
Aug 8 2016
,
Aug 8 2016
,
Aug 8 2016
Yup, I can confirm this. I uploaded a test-case here: https://tests.peter.sh/random/notification-replacement.html Expected test output (green lines): Displayed notifications: #1 Displayed notifications: #2 Displayed notifications: #3 Not three of them like this issue describes, certainly not the additive effect that happens when reloading the page.
,
Aug 8 2016
,
Aug 9 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3ce3c468088599dc190fc596d0780c319ed82d3d commit 3ce3c468088599dc190fc596d0780c319ed82d3d Author: peter <peter@chromium.org> Date: Tue Aug 09 16:23:58 2016 Eagerly delete replaced notifications from the database Don't rely on the close() event to happen, instead, delete them as soon as we know one's being replaced. BUG= 635326 Review-Url: https://codereview.chromium.org/2223943002 Cr-Commit-Position: refs/heads/master@{#410697} [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/content/browser/notifications/notification_database.cc [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/content/browser/notifications/notification_database.h [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/content/browser/notifications/notification_database_unittest.cc [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/content/browser/notifications/platform_notification_context_impl.cc [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/content/browser/notifications/platform_notification_context_unittest.cc [add] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/third_party/WebKit/LayoutTests/http/tests/notifications/serviceworkerregistration-get-replacement.html [modify] https://crrev.com/3ce3c468088599dc190fc596d0780c319ed82d3d/tools/metrics/histograms/histograms.xml
,
Aug 9 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rnimmagadda@chromium.org
, Aug 8 2016