Issue metadata
Sign in to add a comment
|
Web Push - Chrome 66 - Notifications are queued up by the browser
Reported by
mathan.v...@vizury.com,
May 21 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: Chrome version - 66 OS - Windows, Ubuntu Summary - A set of notifications, when delivered at once to the browser, are not displayed immediately, and are queued up internally at the browser. And, this is happening across service workers. 1. Send a burst of, at least, 10 push notifications to the browser. 2. At most, only 2 (small images) to 3 notifications (big images) would be displayed immediately to the user. 3. However, the showNotification() promise would be resolved for all the 10 notifications as they are received by the browser. Eg. If impression beacons are invoked in the resolve of showNotification, the beacons are fired correctly even though the notifications are not displayed yet. 4. The remaining 7 or 8 notifications would not be displayed until the next notification arrives i.e the next time showNotification is invoked on a newly arrived message. 5. As soon as the next new message is received, another 2 to 3 notifications gets displayed from the queue. 6. This continues until the queue becomes empty. Only when the queue is empty, a notifications gets displayed as soon as it is received by the browser. What is the expected behavior? 1. All the notifications should have been displayed in multiple successive batches upon closing of the current notification(s) and depending on the size of the notification and the available real estate on the display. What went wrong? -A set of notifications, when delivered at once to the browser, are not displayed immediately, and are queued up internally at the browser until a new notification arrives. And, this is happening across service workers. Did this work before? Yes 65 Does this work in other browsers? Yes Chrome version: 66.0.3359.181 Channel: stable OS Version: 8.1 Flash Version:
,
May 21 2018
,
May 21 2018
This issue has been observed by others as well - https://productforums.google.com/forum/#!topic/chrome/gPDC69l7D84
,
May 22 2018
Thanks for filing the issue! Able to reproduce the issue on reported chrome version 66.0.3359.181 using Windows 10 and Ubuntu 14.04. Note: Unable to check the issue on Mac as only one notification is being shown at a time. Bisect Information: ==================== Good Build: 66.0.3359.80 Bad Build: 66.0.3359.81 Change log from omahaproxy: https://chromium.googlesource.com/chromium/src/+log/66.0.3359.80..66.0.3359.81?pretty=fuller&n=10000 Suspecting: https://chromium.googlesource.com/chromium/src/+/278ee5ec5ef68d11993c955e4e400c41bb6cdd08 Assigning it to Yoshiki(one of the reviewers) as Evan Stade is unavailable(OOO). @Yoshiki: Please help us in assigning it to the right owner if this not related to your change. NOTE: Issue seems to be fixed on latest Beta 67.0.3396.48, canary 68.0.3437.2 and the very first build in M67 (67.0.3360.0) hence marking it with M-66 milestone, and requesting for a merge in upcoming(...if any) M66 stable release(s). Adding RB-stable, please remove if not required.
,
May 22 2018
Thanks for the quick verification and acceptance! The behaviour in question works fine on Mac platform as the notifications are fine controlled by OS X's Notification Center where no more than a single notification is allowed at any point in time for a given domain. Also, the notification queue gets emptied as soon as they are received by Chrome. Given this is a major break, and has impacted several users, can we expect a hot-fix?
,
May 24 2018
Evan, could you take a look? I think this might be related with the issue you and Tetsui are spending hard time to investigate: Issue 814495?
,
May 24 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsleevi@chromium.org
, May 21 2018