Issue metadata
Sign in to add a comment
|
WebNotification not updated anymore after a certain delay (update resumed on 'onnotificationclick' or when Chrome is re-launched)
Reported by
ka.gema...@gmail.com,
May 28 2017
|
||||||||||||||||||||||
Issue description
Steps to reproduce the problem:
1. Subscribe to a WebNotification service
2. Receive the notification
3. Close the browser
What is the expected behavior?
Latest notifications should carry on being updated in the UI
What went wrong?
There are 2 bugs:
1. Immediately (or after 1 mn) after closing the browser, the next received notification is not updated in the UI. To resume correct display, it requires to trigger the 'onnotificationclick' event.
2. After 10 mn or so, again the notification UI seems to go into hibernation, the latest received notification is not displayed anymore, only the last one received before hibernation is kept being displayed. And again, clicking on a notification action button ('onnotificationclick') resumes a correct display of notifications.
Once the notification action button is clicked, the last notification is not displayed, but the one received after 'onnotificationclick' is then correctly displayed, back to normal.
Also, alternatively to clicking on the notification action button, re-launching Chrome resumes an updated/correct display of notifications, back to normal.
In both cases of "hibernation", dismissing/closing a notification doesn't seem to have any effect on the service worker side, the 'onnotificationclose' event doesn't seem to be triggered.
Seems to be a bug related to service worker going into hibernation, 'ServiceWorkerRegistration.showNotification()' doesn't seem to be called at all.
Also, if normally an HTTP request is to be made after receiving a notification ('push' event) or after a notification is closed ('onnotificationclick' event), in the case of the "hibernation bug" those HTTP requests are not made anymore.
This is a new behaviour happening since 2 weeks or so.
Did this work before? Yes
Chrome version: Beta (59.0.3071.71) Channel: beta
OS Version: 6.0.1
Flash Version: M3.6.51-ZE500KL_20236_8916
There's a third bug which seems related, with the notification completely vanishing when the phone is plugged with USB after a certain delay (but unclear, gotta investigate more). In that case, the display is back to normal when the browser is re-launched.
,
Sep 23 2017
Sorry for being late on the reply, had to switch to other tasks. After investigating with logcat, I seem to have found the issue. It's coming from the Asus Start Manager app/bloatware which blocks notifications by default as described in this forum thread https://www.asus.com/zentalk/in/forum.php?mod=viewthread&tid=62502&page=1#pid295734 . There still seems to be a similar issue when plugging the phone with USB on a computer (unclear, seen once). Anyway, to circumvent that potential problem of "zombie notifications", I've implemented a ping mechanism. Regularly, per notification subscription, a hint is added to the notification which then, when received by the browser, triggers an HTTP PUT pong callback to the server. If no HTTP pong is received after a certain delay, the underlying notification job is stopped and the user notification subscription deleted.
,
Sep 23 2017
Thank you for providing more feedback. Adding requester "ppolisetty@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 25 2017
If a privileged third-party app such as Asus Start Manager is messing with our notifications, there's very little we can do. What do you mean by the Service Worker going in "hibernation"? We kill the Service Worker after a few minutes, and that's by design. Subsequent push messages can update any previously shown notification by using the `tag` property, providing there's nothing in the way. As an aside, I'm really puzzled as to why Asus would do this. By the time we update a notification the resource cost of doing so has already been paid, so it's really just disrupting the user's expectations.
,
Mar 9 2018
***Bulk edit*** Closing due to inactivity, please feel free to reopen if needed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ppolise...@chromium.org
, Jun 2 2017Components: UI>Notifications
Labels: Needs-Feedback