desktop
desktop copied to clipboard
mattermost
linux client forces autoraise
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.
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.
@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)
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.
This is probably a duplicate of https://github.com/mattermost/desktop/issues/1644
@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).
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.
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.
@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... :crossed_fingers:
@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.
@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.
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.
@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.
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 https://github.com/mattermost/desktop/issues/1827#issuecomment-1257214477, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACELVYSSVZ5VYZCOFYCOFYDWABS47ANCNFSM5GJDCINA . You are receiving this because you were mentioned.Message ID: @.***>
@ekimd An Electron issue is open here: https://github.com/electron/electron/issues/28163
Hmm, electron/electron#28163 discusses input focus, not autoraise. That ticket seems to be on a completely different subject to me.
An issue here too (5.2.2, Debian 11, x11). I also uped https://github.com/electron/electron/issues/28163
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: https://github.com/mattermost/desktop/issues/1827#issuecomment-985030561
It seems as though we'll need to file a different Electron issue than the one above.
https://github.com/electron/electron/issues/38184
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.
I've given up with the desktop client and went back to using it from a webpage.
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.
FYI: Same issue happens on Debian 12 (bookworm) with version 5.6 and fvwm as the windows manager.
