Right clicking icon and choosing 'Quit' just minimizes

[DivineOmega]

Running Ubuntu 14.04 and Mattermost Desktop (electron-mattermost) v1.0.7, steps to reproduce:

1. Start up Mattermost Desktop in the normal manner.
2. Right click the icon representing the running program in Unity.
3. Click the 'Quit' menu option.

Expected behaviour:

• Mattermost Desktop exits.

Actual behaviour:

• Mattermost Desktop minimizes if not already minimized and does nothing if it is already minimized.

The only way to quit Mattermost Desktop in this instance is to use the File -> Quit menu option or to kill the process.

[yuya-oc]

On Linux, the application performs 'minimize' instead of 'close' in order to keep the window. It seems that this feature is working in this issue. Unfortunately, I don't know what is the difference between Unity's 'Quit' and normal 'close'.

[brumle80]

same "issue" in Fedora 23, click the x and it minimizes, but doesn't close.

[yuya-oc]

@brumle80 Did you mean about window's "close button"? If you did, the behavior is by design as I had written at the previous post. I think that the point of this issue is the handling for 'Quit' operation caused by desktop environment like Unity/GNOME.

[jasonblais]

Thanks @DivineOmega and @brumle80 for the feedback,

A related ticket #178 has been resolved and closed, which should fix the issue presented here.

However, if there is a further improvement you would like to see, I invite you to help contribute your suggestion in Mattermost feature idea forum so it can be discussed, upvoted and considered for a ticket accepting pull requests?

If you do add it to the feature idea forum, please include a link back to this GitHub Issue. If you're interested in implementing, please say so and we'll prioritize the review.

[jasonblais]

I realized there actually is still an issue with right clicking icon and choosing 'Quit'. I have added it as a known issue to the desktop changelog

[RaphaelKimmig]

@jasonblais Given that this is a known issue in the changelog, should this issue still be open?

[jasonblais]

@RaphaelKimmig I think that's fair

[amyblais]

Ticket for tracking: https://mattermost.atlassian.net/browse/MM-14130

[echosa]

I'm not sure if this is the right issue to tack on to, or if I should create a new one (happy to do so!), but there's an inconsistency in the way "Quit" menu items work in Mattermost, at least in GNOME.

There are are a few "Quit" options but not all work the same:

• In the application window, File -> Quit. This actually quits the program.
• From the tray icon, <right-click> -> Quit. This actually quits the program.
• From the upper-left application menu (next to Activities). <Application menu> -> Quit. **This only closes the window/minimizes to the tray, leaving Mattermost open.
• The Close/X button in the upper-right of the windows. This also only closes the windows/minimizes to the tray, but that's expected... sort of. See below.

So, of these four options, the third seems wrong. <Application menu> -> Quit should completely quit the program, in my opinion.

Now, I can understand the fourth option, since you're "closing" rather than "quitting". However, closing the window is keeping Mattermost open/in the tray, even though I have the "Leave app running [...]" setting unchecked/turned off. See screenshot. Is this a bug? Shouldn't Mattermost be quitting when I close the window since I have that setting turned off?

[bochecha]

In addition to @echosa's last post, there is a 5th way to quit the app in GNOME:

• in the Activities overview, click the (x) button in the top-right corner of the window thumbnail. Nothing happens at all.

I too have the "Leave app running [...]" setting unchecked/turned off" and would expect all 5 ways to completely quit the program.

Enabling the option should really only minimize the app for the window close button (4th case from @echosa's comment), all other cases should always quit the program no matter what.

[aunwin]

Not being able to quit the Desktop Client in the usual way (e.g. klicking the red x button at the top) might cause people to move away from using mattermost.
Under Ubuntu 18_04 LTS I have to use CTRL+q to actually quit the application.

[skewty]

Hey look, another >3 year old bug given low importance due to minuscule Linux market share.

Ticket for tracking: https://mattermost.atlassian.net/browse/MM-14130

Doesn't have any useful information (also showing lack of care about this issue).

Is this an upstream issue? I don't have this issue with other Electron apps. Is it an upstream one? Does anyone have links to the upstream issue(s)?

[amyblais]

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

[aunwin]

Yes. Both for mousclick on the close-icon as well as for alt+F4 Hotkey attempts.

[cookiengineer]

I wanted to confirm that this is still the case with GNOME 3.36 and later. Not a Unity setup, up-to-date Arch + GNOME stable.

Why doesn't mattermost instead use the appindicator API to land in systray if that's the wanted behaviour - and allow users to disable systray integration in order to close it when they want it?

Currently, users have to manually pkill the process, which I think is pretty annoying.

[raphaelmro]

I'm having the same experience on Pop!_OS 19.10 x86_64 and GNOME 3.34.3.
The close-icon minimizes the app and the quit button while on the dock is not triggering any close/kill action.

[cfcohen]

I'm running Mattermost in KDE. In my opinion, closing the window (with the X in the top right corner of the window that normally quits an application) should actually quit the application. This is especially true if the "leave app running in the notification area" is not checked in the settings. That setting is completely disabled on my system, probably because there's no actual KDE notification support. The current behavior just feels like the app is intentionally defeating my attempts to quit, including several other contexts in which an app would normally exit, but instead Mattermost just minimizes (even when it's already minimized, resulting no action). I would recommend just disabling the non-standard close behavior when the setting is disabled.

[SemaiCZE]

Did you mean about window's "close button"? If you did, the behavior is by design as I had written at the previous post. I think that the point of this issue is the handling for 'Quit' operation caused by desktop environment like Unity/GNOME.

@yuya-oc For me it's bad design choice. I'm using Gnome on Fedora and I have UNchecked the Leave app running in notification area switch in settings. On Gnome there is no such thing as notification area and minimizing applications is also not much supported. I'd love to quit Mattermost client the same way as any other app (including Slack). Please reevaluate your design choise. Thanks

[volca02]

On version 4.4.1, while using i3 WM on linux, clicking the red X, or using the i3's close application key combo (which seems to use the WM_DELETE protocol) does nothing at all. That's with the option Leave app running in notification area when application window is closed disabled, I can't seem to be able to enable it.

[cookiengineer]

I created the pull request #1279 and it respects the minimizeToTray setting correctly.

• If minimizeToTray is set to true, hide the main window.
• If minimizeToTray is set to false, close the main window.

[skewty]

@cookiengineer has even done a PR for the fix. Is the PR not acceptable? What is holding this up?

[cookiengineer]

@skewty The current status is that I'm building my own fork because nobody answered on the UI/UX implications for this change and I cannot answer these questions, as I am not affiliated with mattermost anyhow.

The settings UI is currently differently rendered on each platform whereas Windows doesn't even have the option, and therefore is behaving wrong in my opinion; and MacOS has this setting but needs testing from a UX member of mattermost.

PS: As an outside contributor I have no clue on what or whether there are even test scenarios for this, and to be honest it seems as the workflow for accepting (or not) pull requests for UX changes seems to be totally broken and overengineered from the CI perspective.

Therefore I kind of gave up and decided to keep maintaining my fork until somebody else has enough time to deal with the UX debate behind this fix. My fork works and behaves the same on MacOS, Windows and Linux - given the settings are rendered everywhere the same, as they should be in my opinion. The fullscreen on MacOS integration isn't affected by this settings option anyways and has a completely separate code branch.

As long as nobody from mattermost's UX team answers, this will likely not be merged in upstream.

[dontlaugh]

Thanks for your work so far on this. I'm not affiliated with Mattermost, either. But, as a GNOME desktop user, this is a major quality of life issue for me.

[devinbinnie]

Closing as we have other issues for this and a toggle checkbox to determine whether this should happen or not.