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

Sidebar does not highlight workspace with new messages #2844

Open
2 of 5 tasks
paulchen opened this issue Feb 14, 2024 · 7 comments
Open
2 of 5 tasks

Sidebar does not highlight workspace with new messages #2844

paulchen opened this issue Feb 14, 2024 · 7 comments

Comments

@paulchen
Copy link

Search before asking

  • I had searched in the issues and found no similar issues.

Operating System

  • macOS
  • Windows
  • Linux

Operating System Version

Windows 10

It happens on the web browser too?

No, it just happens on the Desktop app

Rocket.Chat Desktop App Version

3.9.13

Rocket.Chat Server Version

6.6.0

Describe the bug

When I'm highlighted, the taskbar icon changes appropriately:

OdhVSsAoeQxqmTMN

The sidebar of the desktop app also highlights the workspace where I'm highlighted:

Q76Rs6i0nYJ9S7TX

When there are only new messages that do not highlight me, the taskbar icon changes as well:

YfPqEskPZzY4oT0m

However, the icon in the sidebar does not change:

0EwXHOY76C1xHxyf

As a consequence, I need to cycle through all workspaces to find out where there is the new message.

How to Reproduce

  1. Set up at least two workspaces in the desktop app.
  2. Configure the notification settings for the first workspace to not highlight you for every new message.
  3. Open the second workspace and keep it open.
  4. With another user, write a message in the first workspace that will be visible to the initial user.

Describe your Expected behavior

Both taskbar and sidebar will change in order to guide me to the new message in the first workspace.

Anything else

I am pretty sure that there was a time when this worked as expected. However, it stopped working some time ago.

Are you willing to submit a code contribution?

  • Yes, I am willing to submit a Pull Request!
@jeanfbrito
Copy link
Collaborator

Hey @paulchen I tested it and worked for me. This happens in how many servers?
Its all the time?

@paulchen
Copy link
Author

paulchen commented Feb 15, 2024

Hey @paulchen I tested it and worked for me. This happens in how many servers? Its all the time?

Yes, it's all the time.

I was just able to reproduce it using a clean Snap-based client installation on Arch Linux that connects to two servers.

Let me clarify that by "sidebar" I mean the list of servers, not the list of channels/groups on one of the servers.

@jeanfbrito
Copy link
Collaborator

Hey @paulchen I tested it and worked for me. This happens in how many servers? Its all the time?

Yes, it's all the time.

I was just able to reproduce it using a clean Snap-based client installation on Arch Linux that connects to two servers.

Let me clarify that by "sidebar" I mean the list of servers, not the list of channels/groups on one of the servers.

But it wasn't on Windows? I don't get this clean Snap-based client installation on Arch Linux that .
I cant say if I don't understood how to reproduce or if it don't happens to me.
Could you provide some screen record showing it happening?

@paulchen
Copy link
Author

But it wasn't on Windows? I don't get this clean Snap-based client installation on Arch Linux that .

Usually I only use the Electron client on Windows 10. That's where I initially observed the problem. By trying a clean installation using the Snap image, I wanted to verify the following things:

  • I can reproduce it in another installation.
  • It does not depend on the operating system.
  • It does not depend on the installation method.
  • It's nothing about the settings on my installation on Windows that may be messed up.

I think I can provide a screen recording, but it will take me some time. I need to take care not to share any sensitive data.

@jeanfbrito
Copy link
Collaborator

No problem. I will try to record my test tomorrow so you can say if I'm testing right.
You disable notifications on desktop on server 1, change to server 2 and send a message using another user on server 1, right?

@jeanfbrito
Copy link
Collaborator

Hey, I released a new version 3.9.14 now, I found a bug that could lead to this issue. So please test this latest version and tell me if the problem persists.

@paulchen
Copy link
Author

Hey, I released a new version 3.9.14 now, I found a bug that could lead to this issue. So please test this latest version and tell me if the problem persists.

Unfortunately, the problem still persists.

I created some screen recordings to showcase the situation:

In the first video, we see the initial situation:

  • On the left side, we see the desktop app in the most recent version (3.9.14).
  • The tray icon is enabled.
  • It is connected to chat-dev.rueckgr.at (running Rocket.Chat 6.6.0) and open.rocket.chat.
  • On chat-dev.rueckgr.at, the user "paulchen" is logged in and member of #general.
  • The message and notification settings are shown. The "Unread tray icon alert" is enabled.
  • On the right side, we see Firefox logged into chat-dev.rueckgr.at with the user "test1".
simplescreenrecorder-2024-02-17_21.34.19.mp4

In the second video, the following happens:

  • The desktop app shows the server open.rocket.chat.
  • In Firefox, the user "test1" writes the message @paulchen def to #general on server chat-dev.rueckgr.at.
  • The desktop app (where the user "paulchen" is logged in) receives a desktop notification.
  • The tray icon of the desktop app shows a "1" denoting one highlight.
  • The server list shows a "1" for the server chat-dev.rueckgr.at.
  • When clicking that server's icon, the channel list shows a "1" for the channel #general.

In summary, the "1"s lead the user "paulchen" step-by-step to the message where they have been highlighted.

simplescreenrecorder-2024-02-17_21.35.05.mp4

In the third video, the following happens:

  • The desktop app shows the server open.rocket.chat.
  • In Firefox, the user "test1" writes the message def to #general on server chat-dev.rueckgr.at.
  • The tray icon of the desktop app shows a dot denoting at least one message in any channel on any server.
  • The server list does not show any dot for the server chat-dev.rueckgr.at
  • When clicking the icon of the server chat-dev.rueckgr.at, the channel list emphasizes #general denoting the channel where a new message has been written.

The main difference to the second video is that "test1" does not highlight "paulchen" in their message. Instead, they just write a simple message to a channel where "paulchen" is joined. After "test1" submits their message, the tray icon will show a dot denoting a new message, but the server list of the desktop app does not lead "paulchen" to the server and the channel where the message has been written.

In my opinion, there should be a dot in the server list for any server where a new message has been written. Maybe the current behaviour is intentional, but as stated in the initial report, I think some time ago such a dot was shown. But maybe I'm wrong.

simplescreenrecorder-2024-02-17_21.35.36.mp4

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

2 participants