Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No notifications from open chat when Chrome is in background #1946

Open
RTechSn opened this issue May 17, 2024 · 17 comments
Open

No notifications from open chat when Chrome is in background #1946

RTechSn opened this issue May 17, 2024 · 17 comments

Comments

@RTechSn
Copy link

RTechSn commented May 17, 2024

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. Have a chat with another account open.
  2. Have no notifications from other apps
  3. Minimize or obstruct your browser window
  4. Send a message from another account

Expected behaviour

Notifications should appear

Actual behaviour

Notifications appear after unminimizing the window, or not appear at all

Talk app

Talk app version: 19.0.0

Custom Signaling server configured: yes/no and version (see Talk administration settings: /index.php/index.php/settings/admin/talk#signaling_server)

Custom TURN server configured: Yes

Custom STUN server configured: Yes

Browser

Microphone available: yes

Camera available: no

Operating system: Windows

Browser name: Chrome

Browser version: 123

@nickvergessen
Copy link
Member

Actually we improved exactly these scenarios in the Talk 18 version. At least when switching to another tab that is.
When overlapping the browser with another window that is not detectable from within the website as far as I recall, but @Antreesy might know more

@ratmix
Copy link

ratmix commented Jun 8, 2024

i also really need notifications to work when the browser tab is not active

@9joshua
Copy link

9joshua commented Jun 8, 2024

Likewise. For me on Desktop the notification is suspended until the Spreed tab is focused - defeating the purpose of the notification.

@RTechSn
Copy link
Author

RTechSn commented Jun 10, 2024

2024-06-10 103325

As you can see, message is received by the client, but the notification is somehow suppressed, until you unminimize the window.

@Antreesy
Copy link
Collaborator

See nextcloud/spreed#10544 :
Conversation session is considered active (and you won't receive notiication for this exact conversation only) when:

  • Tab is active - always;
  • Tab is blurred, but in foreground (visible or obstructed by another window) - first 3 minutes ⚠️;

Then you should see a request like nextcloud.local/ocs/v2.php/apps/spreed/api/v4/room/{token}/participants/state to server with payload 0:
image

Same request is sent when you:

  • Minimize the window to background
  • Switch to another tab in the same window

Though in that case, you shouldn't receive any notifications from server (304 response status). Apart from it, we are not blocking any native pop-ups by code.

@RTechSn
Copy link
Author

RTechSn commented Jun 11, 2024

2024-06-11 100806
@Antreesy I've checked again, here you can see that the session is marked as inactive and the notification has been received by the browser. But there is no pop-up notification, until you focus the window.
This bug occurs only if you have no other notifications and only on Chromium browsers.

@Antreesy
Copy link
Collaborator

I've checked again, here you can see that the session is marked as inactive and the notification has been received by the browser. But there is no pop-up notification, until you focus the window. This bug occurs only if you have no other notifications and only on Chromium browsers.

Thanks for the confirmation, will try to reproduce it

@Antreesy
Copy link
Collaborator

Yep, reproducible for me.
As I understood it, issue seems to be on Notifications app side (frontend):

  • If tab is inactive, browser suspend some processes. In this particular case, a rendering of new components (<Notifcation />) which are creating a natie browser notification.
  • Unless tab is selected as active again (or at least hovered to show a tab preview, which sometimes also triggers a re-render), component won't be mounted.
  • Solution would be to move the native notification creation to the <NotificationsApp />, but that require a rework. Small patch for testing is under details:
// in NotificationsApp
	watch:{
		notifications(value) {
			console.log('watch notifications', value)
			if (value[0]?.shouldNotify
				&& this.showBrowserNotifications
				&& this.webNotificationsThresholdId < value[0]?.notificationId) {
				const n = new window.Notification(value[0]?.subject, {
					title: value[0]?.subject,
					lang: OC.getLocale(),
					body: value[0]?.message,
					icon: value[0]?.icon,
					tag: value[0]?.notificationId,
				})
			}
		},
	},

Transferring this issue to nextcloud/notifications repo

@Antreesy Antreesy transferred this issue from nextcloud/spreed Jun 11, 2024
@Antreesy Antreesy added this to the Nextcloud 29.0.3 milestone Jun 11, 2024
@ShGKme
Copy link
Contributor

ShGKme commented Jun 11, 2024

We are checking only active/inactive state. We can also check for frozen/ discarded states for suspended tabs.

I'd say that a proper solution is to move notifications completely out from any DOM rendering, best to a worker to not be a part of the page that can be frozen.

@nickvergessen
Copy link
Member

While yes, let's first do the quick fix of moving it to the root component

@ShGKme
Copy link
Contributor

ShGKme commented Jun 13, 2024

For the reference:


In a frozen state, DOM is not updated, but background tasks are still running.

In a discarded state, no new task from the task queue will be executed.

So, to support discarded state or true push notifications, we would need to use workers what most of our libraries do not support.

@RTechSn
Copy link
Author

RTechSn commented Jun 26, 2024

This particular issue seems to be fixed in the last update (29.0.3).
Should this issue be closed, or should it remain open, until the proper solution with the support of discarded state be implemented?

@Antreesy
Copy link
Collaborator

should it remain open, until the proper solution with the support of discarded state be implemented?

Yes, we wanted to keep track it and look into web workers usage in the future for handling notifications. You may unsubscribe from receiving a notifications from this issue to not suddenly be bothered one day. Thanks again for the help with investigation!

@MohammedNoureldin
Copy link

MohammedNoureldin commented Jun 27, 2024

Hi

I have issues generally in Nextcloud notifications. In both Desktop PWA and in browser. The notifications do not arrive and are not shown when the Windows is minimized (PWA and NC webpage). As soon as I open the Window, the notifications are shown (not always quickly, but at least they arrive).

The notifications are in general too slow.

Is it related to this issue and planned for 29.0.4, or is it not related?

I am using 29.0.0

@nickvergessen
Copy link
Member

I am using 29.0.0

Then update please. Mostlikely it's fixed in 29.0.2 via #1948

@MohammedNoureldin
Copy link

MohammedNoureldin commented Jun 27, 2024

Thanks a lot @nickvergessen! I confirm that it works now with 29.0.3.

Nevertheless, the notification on the desktop (Web or PWA) is slow, it takes always about 20-30 seconds for the notification to arrive and get shown in Windows. Is there anything we can do for it?

@nickvergessen
Copy link
Member

Is there anything we can do for it?

Yeah we do 30 second polling. So can be between 0 and 29 seconds.
You can install this additional tool that will create a websocket connection with the clients and browser so that notifications can be pushed live: https://github.com/nextcloud/notify_push

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants