The windows desktop client should not flash frame on noisy (loud) notification

[tomvaneyck]

The problem:

When receiving a noisy (loud) notification on the desktop client, the window is flashed using the FlashWindow API. This makes the icon on the taskbar go orange and pops up the taskbar if it is normally automatically hidden. This is especially frustrating when it then hides something I'm looking at.

The typical function of the FlashWindow API is described in the remark on MSDN:

Typically, a window is flashed to inform the user that the window requires attention but that it does not currently have the keyboard focus.

I want to argue that the window does not require immediate attention when receiving a message.

One could say that I should change the notification from noisy to on, but then the notification would not play a sound. Basically it's all or nothing.

My solution:

Do not flash the window.

This is how the web client works and is in my opinion a much nicer way to handle notifications.

It is easily possible to change this by removing the flashFrame call from this function:

ipcMain.on('loudNotification', function() {
    if (process.platform === 'win32' && mainWindow && !mainWindow.isFocused() && !focusHandlerAttached) {
        mainWindow.flashFrame(true);
        mainWindow.once('focus', () => {
            mainWindow.flashFrame(false);
            focusHandlerAttached = false;
        });
        focusHandlerAttached = true;
    }
});

Another solution would be to add a setting to enable and disable this functionality. I do not like this, because 1) it is much harder to implement and 2) this is not in line with the different clients.

If someone has a better idea on how to handle this, please comment below.

[ShadowJonathan]

Are you asking that the window is not flashed when it is in focus, or that it doesn't flash at all?

Discord has the same behaviour, it flashes the window whenever you get a new mention-notification, so i'm assuming you mean the former; don't flash the window when it's focused(?).

[tomvaneyck]

I am asking that, when the window is not focused, it is not flashed when receiving a notification. Discord indeed does the same, but allows the flashing to be switched off. Signal allows to turn it off as well and Slack never flashes in the first place.

[t3chguy]

This was done by user request in the first place, so now we're in a place where some users want it some don't so at best it may be a default-on option, like Discord.

[kmohrf]

This feature was recently enabled for Linux but I’m not really sure if the consequences were entirely clear. flashFrame on Gnome forces a workspace and focus switch and I haven’t found a way to turn that off in Gnome yet. I do want audible notifications but I very much don’t want my desktop to randomly switch to element whenever someone is messaging me. It is very distracting. It seems like coupling the flash frame action to the audible/loud notifications setting is questionable at this point.

Relevant closed bug report #1714.

[t3chguy]

@kmohrf that sounds like a Gnome issue, flashFrame on linux sets the demands attention flag. The spec says nothing about it needing to steal the user's focus.

_NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or with the window happened. For example, it may be set by the Window Manager if the window requested activation but the Window Manager refused it, or the application may set it if it finished some work. This state may be set by both the Client and the Window Manager. It should be unset by the Window Manager when it decides the window got the required attention (usually, that it got activated).

https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html

[kmohrf]

@t3chguy Nice! I was searching for an explanation of what flashFrame actually does on Linux given that the docs for electron are pretty vague. I agree that the spec does neither require nor imply that the desktop environment should switch focus.

However, my point still stands: the setting is called Enable audible notifications for this session and it really does more than that (especially now that we know that it has some very drastic implications in Gnome). I’m not saying that this feature should be changed (though I do wish that there were separate settings). When I was trying to figure out how I can disable this behavior I stumbled upon a Reddit post that mentioned a Draw attention to the window setting in the Telegram desktop app. That sounds like a reasonable wording given the actual behavior it will trigger and I (and others) might have attributed that correctly. Therefore a reasonable short-gap measure might be to just rename the setting to better reflect its implications.

Furthermore it might be interesting to know how other popular Linux desktop environments apart from Gnome have implemented the _NET_WM_STATE_DEMANDS_ATTENTION flag. If most of them have implemented focus-switch-behavior that might have an impact on the usage of flashFrame on Linux.

[t3chguy]

Furthermore it might be interesting to know how other popular Linux desktop environments apart from Gnome have implemented the _NET_WM_STATE_DEMANDS_ATTENTION flag. If most of them have implemented focus-switch-behavior that might have an impact on the usage of flashFrame on Linux.

https://github.com/signalapp/Signal-Desktop/issues/3582 seems like for some users, it is essential to their wm functioning correctly.

[aebenjam]

Totally acceptable, IMHO, to make it a default-on option... but I want to turn it off. I'm not using Gnome, I'm using Fwm3, and it raises the window and pulls my mouse focus to it. Like the original poster of this thread, I find that painful. I want the audible notification and that's it. The window can stay where it is until I'm ready. Otherwise it interrupts my typing mid-flight, occludes what I was looking at, etc. I could minimize Element to the system tray all the time, but sometimes I want to be able to glance over at the new message without having to move my mouse away and back, etc. Please, and thanks.