Desktop: mm-desktop not respecting graceful shutdown messages on linux/i3

[vobie]

I confirm (by marking "x" in the [ ] below: [x]):

• [x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
• [x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• [x] I have read contributing guidelines.

---

Summary
Mattermost-desktop on linux does not respond to requests for graceful shutdown. At least not when running i3 window manager.

Steps to reproduce
i3wm method 1
Focus window and use MOD-SHIFT-Q (default config) to try and close the window

i3wm method 2
sleep 3s && i3-msg kill - focus window within three seconds and wait. Terminal output indicates success by [{"success":true}]

xdotool and wmctrl

1. xdotool search --name Mattermost - if for any reason multiple IDs show up, use some other string unique to the mattermost window title. This should output a window ID
2. wmctrl -i -c <id>

The first method works for every other application I use. The other two work at least for chromium, firefox and xterm.

OS Linux HOSTNAME 5.0.3-arch1-1-ARCH #1 SMP PREEMPT Tue Mar 19 13:09:13 UTC 2019 x86_64 GNU/Linux
Mattermost version 3.7.1 (Update: Got version 4.2.1, problem remains)
Server version
Mattermost Version: 5.8.1
Database Schema Version: 5.8.0
Database: postgres

Expected behavior
The window should close and the process should exit. Alternatively, since the methods above are requests for graceful shutdown, an "Are you sure?" prompt should be shown.

Observed behavior
Nothing happens.

Possible fixes
I have little knowledge on such things but it appears to be related to WM_DELETE_WINDOW which appears to be the 'nice' way to shut down an application. For example, when using the above methods on chrome while I have started typing a message on some site, a prompt asking me if I'm sure I want to shut down appears.

Slice of i3 log where WM_DELETE is sent.

04/17/2019 04:31:33 PM - bindings.c:get_binding:239 - binding_keycode->modifiers = 66, modifiers_mask = 66, modifiers_state = 81, mods_match = no
04/17/2019 04:31:33 PM - bindings.c:get_binding:239 - binding_keycode->modifiers = 80, modifiers_mask = 80, modifiers_state = 81, mods_match = no
04/17/2019 04:31:33 PM - bindings.c:get_binding:239 - binding_keycode->modifiers = 82, modifiers_mask = 82, modifiers_state = 81, mods_match = no
04/17/2019 04:31:33 PM - commands_parser.c:parse_command:265 - COMMAND: *kill*
04/17/2019 04:31:33 PM - commands.c:cmd_criteria_init:151 - Initializing criteria, current_match = 0x55c5ce178300
04/17/2019 04:31:33 PM - commands.c:cmd_kill:1180 - kill_mode=window
04/17/2019 04:31:33 PM - con.c:con_close:275 - Closing con = 0x55c5ce28de30.
04/17/2019 04:31:33 PM - tree.c:tree_close_internal:201 - closing 0x55c5ce28de30, kill_window = 1
04/17/2019 04:31:33 PM - Sending WM_DELETE to the client
04/17/2019 04:31:33 PM - commands.c:cmd_criteria_init:151 - Initializing criteria, current_match = 0x55c5ce178300

---

JIRA tickets are created for all valid bug reports filed here. Bugs and features that the Mattermost core team are not immediately working on are opened as Help Wanted GitHub issues and welcome to contributions.

Our goal is to bring the Mattermost desktop repository into our day-to-day internal process with the hope of having more frequent desktop releases with faster feature development and turnaround time on bug fixes.

[amyblais]

@yuya-oc / @wget / @svelle / @JtheBAB Do you know if there is a bug here for me to open a bug ticket?

[svelle]

I don't think there is an issue open for this yet. But I experience the similar behavior on Gnome in Fedora as well, where clicking the close button in the window overview doesn't actually close the Client.

My first guess would be that this is in relation to MM continuing to run in the background.

I guess this could be considered a bug since it is quite different to how other apps behave on these systems.

[amyblais]

Ticket here: https://mattermost.atlassian.net/browse/MM-15281.

[ryliejamesthomas]

Came to post the same issue!

[nigels-com]

Same problem here. Poor user experience when the user has lost control of closing applications as appropriate. In my case it had lost connection with the server and periodically grabbing focus and popping up alerts. In the end I removed the package and killed with -9 at a bash prompt. But clearly that sort of intervention shouldn't be necessary.

[amyblais]

Are you still experiencing this issue on desktop v4.4.0?

[BenElgar]

Yes, I'm still experiencing this in v4.4.0.

[jaycee]

This is still an issue.

[wget]

I think this is related to electron. Maybe bumping that version could help. We are /way/ out of date on that regard. We are usually on release - 1, but at this time of writing, latest stable is v 10, so we should be at v 9, but we are effectively still at v 7 :(

@Willyfrog what would be the work required to bump the electron platform? This is becoming a major issue. On Arch, the package is at risk at being thrown out of the repo :/ Users and others packagers are complaining. All chat competitors did the switch already.

[Willyfrog]

i'm currently working on migrating to browserview and it will bump to electron 10, but no plans to migrate while keeping webview.
you can check electron's breaking changes to get an overview of needed work (mostly taking care of ipcCommunications and try to minimize usage of remote

[wget]

browserview

@Willyfrog What's the advantage of browserview? Will it allow (in the future) to reuse the system Chromium based engine?
e.g.: https://twitter.com/MSEdgeDev/status/1318248720530460674

[Willyfrog]

no, I'm afraid the one you linked seems to be a windows only thing.

we are currently using webview tag, which is a google chrome's feature that is not really stable and compatibility sometimes break. It was the only option to embed a browser in electron, but figma added this other to electron which has a better support although is less configurable