linux client forces autoraise

[jheidemann]

Summary

Recently (after Sept 1, 2021?), the Linux client for mattermost began forcing autoraise--autoraise should be up to the user (like before).

Steps to reproduce

Run mattermost desktop client for Linux version 4.7.2 under Wayland (I'm using Fedora 34, if that matters).

Expected behavior

If the window is behind other windows but partially exposed, moving the mouse over it should NOT raise the whole thing.

Autoraise should be up to the user and their window manager. MM should not force autoraise.
(Autoraise is particularly obnoxious when I'm trying to resize a window over MM. If I miss the window's edge
and touch MM, MM jumps in front. Ick!)

Observed behavior (that appears unintentional)

Moving the mouse over any part of the MM window immediately raises the entire window.

Possible fixes

Revert the recently added autoraise code.

[amyblais]

@jheidemann Are you able to reproduce this on Desktop app v5.0?

[jheidemann]

Sorry, I didn't realize I was behind a version.

But YES, the same problem (mandatory autoraise) appears with mattermost desktop app 5.0.0, the currrent version.

[amyblais]

Thanks, opened a ticket: https://mattermost.atlassian.net/browse/MM-39357

[devinbinnie]

@jheidemann I'm unable to reproduce this myself under Ubuntu 20.04 running GNOME on Wayland. As far as I can tell, there was no 'autoraise' code that was added to the Desktop App, nor do I see any reports to Electron about the issue. Do any other apps exhibit the same behaviour, specifically Electron apps? (eg. Discord, Slack)

[jheidemann]

I'm running Gnome-shell-40.4 on Fedora 34, with focus-on-hover (not click to focus) in the global settings, and focus-follows-mouse (which must be set by running gsettings set org.gnome.desktop.wm.preferences focus-mode sloppy). Maybe Ubuntu has an older version of gnome, or maybe those settings matter?

I don't have discord. I do have slack, and it does not autoraise.

[lkraav]

This is probably a duplicate of #1644

[jheidemann]

@lkraav: I think #1644 is different from #1827 (this ticket). #1644 is about where focus is (where keyboard typing goes). This ticket (#1827) is about autoraise: what's on top. In some window managers, the two are always done together. But not always. With gnome-shell, with the configurations described two posts back, one can give focus to a window without it being on top. Except the mattermost window, which always raises itself (the issue in this bug).

[devinbinnie]

Sorry for the slow response.

Was able to reproduce, however I don’t think this is something we can fix.
Currently in order to make sure that focus returns back to whatever BrowserView we were last using (either one of the MattermostViews or a modal), we have to manually focus() the BrowserView, which is what causes this issue on Sloppy Focus, because calling that method seems to raise the window, and there doesn’t seem to be anyway to stop it.

There's an electron issue here to fix the issue where the BrowserView doesn't automatically get focus back when the window does, but it doesn't seem to have any attention at this time.

[jheidemann]

On Thu, 02 Dec 2021 13:52:59 -0800, Devin Binnie wrote: Sorry for the slow response. Was able to reproduce, however I don’t think this is something we can fix. Currently in order to make sure that focus returns back to whatever BrowserView we were last using (either one of the MattermostViews or a modal), we have to manually focus() the BrowserView, which is what causes this issue on Sloppy Focus, because calling that method seems to raise the window, and there doesn’t seem to be anyway to stop it. There's an electron issue here to fix the issue where the BrowserView doesn't automatically get focus back when the window does, but it doesn't seem to have any attention at this time.

I'm glad you could reproduce the problem. I don't know anything about Electron, but certainly other apps handle sloppy focus without requiring autoraise. But maybe Electron makes that hard. I hope eventually the upstream ticket will get addressed, and perhaps that will propagate down and fix my problem. Thanks for following up.

[runejuhl]

@devinbinnie thanks for looking into this. As it is I'm stuck on Mattermost 4.6.2-7881; anything later is in practice unusable, and the situation is slowly getting worse as server-side Mattermost is upgraded -- for instance the channel switcher now no longer sorts the entries by unread messages.

I agree with @jheidemann's observations -- Mattermost must be doing something radically different to other Electron-based apps. I really hope that you manage to get the issue resolved soon, in upstream or in Mattermost... 🤞

[devinbinnie]

@runejuhl We are making heavy use of BrowserView which I don't think a lot of other Electron apps do. We do this in order to support multi-servers and tabs simultaneously and seamlessly. In the future we're looking to migrate to getting rid of BrowserView but that's unfortunately a long way out at this point. Hopefully Electron can resolve the issue in time.

[ekimd]

@devinbinnie Would you be able to open a ticket with Electron regarding this? I'm sure you'd be able to provide a lot better detail than if I try to open a ticket with them. Thank you!

We are making heavy use of BrowserView which I don't think a lot of other Electron apps do. We do this in order to support multi-servers and tabs simultaneously and seamlessly. In the future we're looking to migrate to getting rid of BrowserView but that's unfortunately a long way out at this point. Hopefully Electron can resolve the issue in time.

[ekimd]

Any movement on this? Does anyone know if a ticket was opened with Electron? I think it makes a lot more sense for a developer to open the ticket than a user because there are likely to be additional questions that the users are too unfamiliar with to speak intelligently.

[devinbinnie]

@ekimd Sorry it's been a while since I've looked at this. Can you reproduce on the latest version (v5.1.1)? We've made some Electron upgrades recently.

[bmnave]

I can confirm this is still an issue in v5.1.1

[ekimd]

Likewise still an issue for me on v5.1.1.

…

On Sun, Sep 25, 2022 at 9:05 AM bmnave ***@***.***> wrote: I can confirm this is still an issue in v5.1.1 — Reply to this email directly, view it on GitHub <#1827 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACELVYSSVZ5VYZCOFYCOFYDWABS47ANCNFSM5GJDCINA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[devinbinnie]

@ekimd An Electron issue is open here: electron/electron#28163

[jheidemann]

Hmm, electron/electron#28163 discusses input focus, not autoraise. That ticket seems to be on a completely different subject to me.

[bmerry]

Can confirm that this is still an issue on 5.2.0.

[bmnave]

Can confirm that this is still an issue on 5.2.0.

+1

[holajsh]

I'm on 5.2.2 and the issue is still there and annoying ;)

[pwollny]

An issue here too (5.2.2, Debian 11, x11). I also uped electron/electron#28163

[devinbinnie]

Having another look at this one, and I've got a bit more info:
Looks like what happens is anytime you call .focus() on any webContents attached to the window, it will raise the window. This only reproduces on Linux (GNOME specifically is what I tried). It doesn't matter if you have focus-on-hover enabled or not.

This is affecting focus-on-hover users as per this comment: #1827 (comment)

It seems as though we'll need to file a different Electron issue than the one above.

electron/electron#38184

[joho1968]

And still an issue on 5.4.0 ...

[jin-eld]

I am observing this issue with Mattermost Desktop Version 5.5.1 commit: db8645b, running the Appimage on Fedora 37 with MATE desktop. My window manager is configured not to automatically raise windows that receive focus, but each time I move the mouse over the Mattermost client it raises itself to the top.

[ekimd]

I've given up with the desktop client and went back to using it from a webpage.

[jin-eld]

I've given up with the desktop client and went back to using it from a webpage.

Tough for people like me who keep ~1k of tabs open, which is one of the reasons why I am not a fan of having any chats in a web browser.

I understand we need to annoy the Electron folks more, I did post there as well.

[schallee]

FYI: Same issue happens on Debian 12 (bookworm) with version 5.6 and fvwm as the windows manager.

[SalmonFOX]

Any updates?

Still the same issue on

• Ubuntu 22.04.4 LTS
• GNOME 42.9
• mattermost server version 9.6.1
• mattermost client Version 5.7.0 commit: e999e2c

[devinbinnie]

Likely still an issue - since the above Electron issue hasn't had any motion yet.

[iox]

Still an issue in 5.8.0 in Kubuntu 22 (KDE). I was really annoyed because I could not use my shortcuts to switch between virtual desktops while Mattermost was focused. Going to System Preferences and changing the focus prevention rules helped to alleviate the issue.