I’ve noticed across multiple mattermost-desktop 4.x versions that when I am in the middle of typing and someone from another channel messages me, the app will occasionally completely freeze for up to 30 seconds.
I’ve seen a similar report for Windows 10 users but that says it was fixed 2 years ago:
Steps to reproduce
I can’t reproduce it every time. But it always happens if I am in the middle of typing a message in the current channel, and then I receive a message and badger counter update from another channel.
This has occurred across multiple versions of mattermost-desktop 4.x, including 4.0.1, 4.1.2 and 4.2.0.
Ubuntu Linux 16.04
Expected behavior
I would expect the app not to completely freeze when other message notifications are received.
Observed behavior
Entire application will lock up for up to 30 seconds. Then suddenly it will catch up and flush the pending characters that I had typed, to the text box.
As a follow up to this issue, I have polled my colleagues on the problem and a number of them report the same experience, being related to the process of typing while a message is being delivered in another channel. No one is 100% the exact factors.
Thanks @JtheBAB
I’m having trouble building it from source on my work machine that is behind a firewall on a private network. I will happily test 4.3.0 if there is a linux amd64 deb?
Thanks for the update from your end. As of now, the 4.3.0 build is yet to be released to public based on the Mattermost desktop changelog. The current stable release is still at 4.2.3.
Based on your response last June 6, can I please confirm if the issue completely not reproducible when you were running the 4.3.0 RC build?
Sorry for the confusion. I had originally gone from an official 4.1.x release to the 4.3.0 RC and confirmed that I hadn’t seen freezes. Then Mattermost went back and released an official 4.2.x and I ended up getting bumped down on my workstation and started seeing freezes. Now I have bumped it back up to the RC and it hasn’t frozen.
No worries and thanks for the confirmation. For now, let us wait for version 4.3 to be officially released and verify that the problem is fixed completely.
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. :-/
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…
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. Basically a DOS attack then.
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?
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.
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.
Basically a DOS attack then. 