Mattermost, Inc.

Desktop App freezing when typing + notification

Is there any feedback on freezes with 4.3.x on Linux so far?

I’m currently experiencing “freezes” in Ubuntu-18.04-based KDE Neon with Mattermost 4.3.1 and:

  • KDE Frameworks 5.64.0
  • Qt 5.13.2
  • xcb Window System

The application window does not accept any input any more as soon as a notification is triggered.

The windows is not completely frozen, though, new messages arrive in all channels and also window updates like availablility or “xxx is typing…” messages work. I just cannot perform any action in the window, it does not react to any mouse clicks or button presses. :-/

Can you share log errors via https://docs.mattermost.com/install/desktop.html#reporting-issues?
Can you help take a look at the troubleshooting guide via https://docs.mattermost.com/install/desktop.html#desktop-app-window-is-black-and-doesn-t-load-the-page?

I’ve been running 4.3.0-develop since Sept 10th, and I haven’t seen any freezing with that version. I’ve just now updated to 4.3.1 so I hope there is not a regression.

  • No errors in the logs. (Neither Electron/application wrapper log nor server specific log.)
  • I disabled GUI acceleration.
  • I refreshed caches.

It does not help. Interestingly, at the moment the window freezes for about a minute or two, after which it resumes again.

As I wrote, in my case the application stays functional and shows new messages, the sound notification plays and everything. It just does not react to any user input, neither mouse nor keyboard. The debug windows are also frozen and do not react in this state.

I use the MM client on a laptop and did not experience freezes yesterday at home, where I use a different dock. No idea, if this might be related, even though I have no idea how it should be…

In any case, it’s pretty annoying, as everything MM is stuck, I cannot dismiss it’s notification in the task bar, and the task bar covers half of my screen (ok, not as much…). This way, the MM client is only barely usable, though, and more some kind of a hurdle than a help… I hope someone has an idea…

1 Like

Our team wasn’t able to reproduce this and suggested that the Ubuntu 18.04 and outdated graphics stack could be at fault here.

I can say it definitely occurred for me on Ubuntu 18.04 when using pre 4.3.0-develop.

I could try to update to the hwe drivers if this might help? And I’m already running Ubuntus Kernel 5.0.0 on my 18.04.

However, it’s not clear to me how (outdated) display drivers should interact this way, as - as I wrote - the application itself does not freeze and display update and everything works just fine.

It just does not respond to input events for a (long) while. To incoming messages etc. it responds just fine, displays those immediately and plays it’s notification sounds. I just cannot answer then, until input is accepted again. So if someone writes many messages over a longer amount of time, one after another will appear immediately as soon as they’re sent, I cannot reply to him or her at all. :wink: Basically a DOS attack then. :wink:

In the office I’m using a Thunderbolt 3 dock where my screen, speakers and USB devices are attached, while at home, where I did not noticably observe those input freezes so far, I’m using an USB-C dock (at the same connector) for this. Might this have something to do with the freezes?

Ok, a bit additional, new information:

I had not enabled the Ubuntu Xorg “Hardware Enablement Stack” (HEW), which is an official Xorg upgrade for Ubuntu LTS. I did so now, but it did not change the freezes, unfortunately.

The kernel HWE stack was already installed.

Contrary to my first impression, the freezes also do not seem to be related to the Thunderbolt dock and also happen at locations where I use USB-C docks.

Still, the freezes only happen most of the time, not always. Unfortunately, I wasn’t able to determine a pattern so far.

The desktop app is basically unusable for me, though. :frowning:

Mh, apparently I was wrong… Now it also freezes after I restarted the application.

Wrong Description of how I thought the application would behave (but apparently doesn't...)

It has been a while, and I’m still suffering from this problem, but I also have a new observation:

The intermittent freezing seems to happen if the Mattermost Desktop client was autostarted during login. If I terminate the desktop client and restart it manually, it seems to work…

I’m using KDE Neon, currently using Plasma 5.18.0, KDE Frameworks 5.67.0, KDE Applications 19.12.2.

Any hints / ideas?

We see frequent freezing of the desktop app on several MacOS based machines.

@nanocosmos-ol

Does this happen when you load a specific channel or randomly? Also, go to the View menu and select Developer Tools for Current Server and see if there are any error messages.

Just happened here again, seems to be random.
see the log file. It shows network disconnects which were not apparent to me,
not sure if this is related but it happens frequently on WiFi, LAN,
and also other laptops in other networks.
https://pastebin.com/xA0uNzz9

Also on another machine
https://pastebin.com/a7vdDFs3

@paulrothrock Do these logs help?

Hi, @nanocosmos-ol

Besides the ERR_NAME_NOT_RESOLVED and ERR_TIMED_OUT that I can see from the log, I noticed the following as well:

websocket_client.jsx:49 websocket re-established connection
websocket_actions.jsx:481 channel broken because of too many incoming messages
websocket_actions.jsx:481 channel broken because of too many incoming messages 

Since the app complains that the channel is broken due to the incoming messages, can you share a little more on the following:

  • Mattermost Server version
  • Mac OS version
  • Mattermost Mac OS app version (if you are not on the latest version, can you upgrade to the latest 4.4.0?)
  • The number of open channels / DM on the RHS channel list

Server Version: 5.19.0 (integrated with gitlab)
Build Number: 5.19.1
MacOS: different versions, 10.13, 10.14, 10.15
MacApp version 4.4 (latest), running from source / electron same issue
Open channels: about 30 with about 20 users
(what is RHS channel list?)
Is it possible to book professional support to work together on this?
Can you send me a direct message?

Hi, @nanocosmos-ol

I have sent you a direct message to troubleshoot this issue further. Thanks.

Same problem popped up for me on a new machine.
GPU accel already disabled.
Old machine was Manjaro (latest, mattermost-desktop 4.4.0, no problem)
New machine, same setup but XFCE instead of KDE desktop
I cant even make use of the webkit debugger console as that one is completely unresponsive as well, stops rendering anything, turns black and crashes mattermost after a minute.
Whenever mm-dektop receives a messages it’s unresponsive for about a minute, barely usable in this state.

Freeze only happens if client has no focus on receiving a message. And apparently only with XFCE desktop. So probably something is going haywire with the notification framework used/involved

Temporary solution for everyone experiencing this problem:

/usr/bin/chromium --profile-directory=Default --app=https://your.mattermost.server…

Put it in Autostart and be happy.
Also Notifications are finally working as intended with this solution as it uses the chromium Framework for that

Hi, everyone.

Update on this. @nanocosmos-ol shared this to me:

but at the same time, would like to know if @Xnyle 's solution can also help. Maybe you might want to give it a try.