Red dot always shown in Safari even though there are no notifications and web push permissions have already been denied

[passibe15]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Open Nextcloud on Safari
2. Click bell icon with red dot
3. If asked, deny web push permissions
4. Open Nextcloud in new tab
5. Notice red dot on bell icon
6. Click bell icon
7. There are no notifications

Expected behaviour

If there are no notifications and web push permissions have been denied, a red dot should not be displayed

Actual behaviour

Red dot it displayed even tough web push permissions have been denied and there are no notifications

Server configuration

Web server: Nginx

Database: MySQL

PHP version: 8.5

Nextcloud version: 33.0.5

List of activated apps

not relevant

Nextcloud configuration

also not relevant

Browser

Browser name: Safari

Browser version: 26.5 (21624.2.5.11.4)

Operating system: macOS Tahoe 26.5

Browser log:

[Info] Notifications permissions not yet requested (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Has notify_push enabled, slowing polling to 15 minutes (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Polling interval updated to 900000 (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Started background fetcher as session_keepalive is enabled (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Got notification data, restoring default polling interval. (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)

---

Additional Info:

I believe the dot is shown because of webNotificationsGranted === null, see

notifications/src/NotificationsApp.vue

Line 18 in 9ca979d

:showDot="notifications.length !== 0 || webNotificationsGranted === null"

This is because none of the scenarios covered by the if-tree in checkWebNotificationPermission() match, so null is returned (which is also why Notifications permissions not yet requested)

notifications/src/NotificationsApp.vue

Lines 539 to 566 in 9ca979d

	checkWebNotificationPermissions() {
	if (!('Notification' in window)) {
	console.info('Browser does not support notifications')
	this.webNotificationsGranted = false
	return
	}
	if (window.Notification.permission === 'granted') {
	console.debug('Notifications permissions granted')
	this.webNotificationsGranted = true
	return
	}
	if (window.Notification.permission === 'denied') {
	console.debug('Notifications permissions denied')
	this.webNotificationsGranted = false
	return
	}
	if (!window.isSecureContext) {
	console.debug('Notifications require HTTPS')
	this.webNotificationsGranted = false
	return
	}
	console.info('Notifications permissions not yet requested')
	this.webNotificationsGranted = null
	},

Curiously, from the browser console, window.Notification.permission returns default, even though Nextcloud had previously already requested web push permissions and I had not granted them. This is also reflected in Safari's settings:

When removing the entry within Safari's settings and reloading the window, I get asked for notification permissions again. If I click deny and refresh again, everything is working fine and there is no red dot:

[Debug] Notifications permissions denied (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Has notify_push enabled, slowing polling to 15 minutes (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Polling interval updated to 900000 (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Started background fetcher as session_keepalive is enabled (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)
[Debug] Got notification data, restoring default polling interval. (NotificationsApp-iD1fLC7v.chunk.mjs, line 86)

This time, window.Notification.permission correctly returns deny.

However, after opening Nextcloud in a new tab, the red dot appears again, the log again shows Notifications permissions not yet requested and window.Notification.permission returns default again.

It seems like window.Notification.permission is not reliable on Safari, leading to the red dot appearing when it shouldn't. A quick google search led me to a Reddit thread, where in the comments someone mentioned using pushManager instead, so maybe that is the solution? This is probably also what #2969 is about?

Thanks for looking into this!

[nickvergessen]

I can reproduce, but the problem is pushManager is only available in a service worker it seems.

[passibe15]

Thanks for your reply and the confirmation!

After doing some more research, it turns out pushManager is also broken:

> reg = await navigator.serviceWorker.getRegistration()
[Info] ServiceWorkerRegistration {installing: null, waiting: null, active: ServiceWorker, navigationPreload: NavigationPreloadManager, scope: "https://cloud.example.org/", …}
> await reg?.pushManager.permissionState()
[Info] "prompt"

So it unless permission is granted, it returns prompt, which I believe is pushManager.permissionState()'s equivalent of window.Notification.permission's default.
The same happens when using navigator.permissions.query, this also just returns prompt, even though it should be denied.

> await navigator.permissions.query({name: 'notifications'})
[Info] PermissionStatus {state: "prompt", name: "notifications", onchange: null, addEventListener: function, removeEventListener: function, …}

So unless I'm missing something, in Safari there doesn't seem to be a way to tell whether a user has denied web push permissions or has simply not been prompted yet. Given that this seems to have been around for a long time (see here and here, maybe it is not possible to fix this cleanly.
Maybe it would be best to get rid of the red dot in case of webNotificationsGranted === null specifically for Safari? Sooner or later the user is going to click on the bell icon anyways and get prompted for giving permission. As it is right now, the red dot is more or less useless on Safari, because it's constantly there …