Main window doesn't receive focus when Mumble-specific Windows notification is clicked

[Snowknight26]

Description

Most programs that can generate a Windows notification have their main window activated whenever the notification is clicked.

Mumble, on the other hand, seems to be the only program that activates the main window in the background. As a result, if Mumble is either minimized to the system tray or its main window is not in focus, clicking on the notification does not bring it to the foreground and focus the main window.

This is especially inconvenient when a maximized window is already in focus, as after clicking on the notification you then also have to click on Mumble in the taskbar (or Alt+Tab, etc.).

I've added a video showing the reproduction steps and issue in action.

Steps to reproduce

1. Minimize Mumble to system tray or bring another window to the foreground (so that Mumble is in the background)
2. Click a notification that Mumble generates (such as by having someone send a message to the channel you're in)

Mumble version

1.4.230

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

2022-05-26_00-25-03.mp4

[Krzmbrzl]

I know that I have tried bringing something to the foreground on Windows on different occasions and the result was always that it is not possible as Windows places very strict rules on when this is allowed.

See also https://stackoverflow.com/questions/5919928/qt-need-to-bring-qt-application-to-foreground-called-from-win32-application.

However, in this specific case, it might indeed work as here Mumble should be the kast application to receive an input event (the click on the notification), so I guess it would be worth a try.

[Snowknight26]

Was browsing the source code and realized that you already handle the signal that the Qt framework emits whenever the notification is clicked.

mumble/src/mumble/MainWindow.cpp

Line 173 in 74faaba

connect(qstiIcon, SIGNAL(messageClicked()), this, SLOT(showRaiseWindow()));

MainWindow::showRaiseWindow calls activateWindow, which coincidentally states:

On Windows, if you are calling this when the application is not currently the active one then it will not make it the active window. It will change the color of the taskbar entry to indicate that the window has changed in some way. This is because Microsoft does not allow an application to interrupt what the user is currently doing in another application.

Seems to be exactly what's happening, though I'm sure there has to be a way to activate the window properly seeing as other applications can. Not going to dig further though as I'm out of my depths here.

[Krzmbrzl]

Ah yeah then this is exactly the behavior that I had in mind.

In this case I'll just close this issue as an "upstream bug" where "upstream" in this case is Windows itself. If even Qt themselves state that this won't work, then I don't see a big chance of use somehow circumventing Windows's restrictions here.

[Snowknight26]

Not sure I agree that this is an upstream bug.

I made a test C# win forms project, created a simple form with one TextBox and one NotifyIcon.

Form class was something along the lines of (click/resize/activate/etc. event handlers simply bind to the functions outlined below so not including the rest of the class):

   public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            notifyIcon1.Icon = Properties.Resources.Icon1;
            notifyIcon1.BalloonTipIcon = ToolTipIcon.Info;
            notifyIcon1.BalloonTipText = "Test!";
        }

        private void Form1_Resize(object sender, EventArgs e)
        {
            if(this.WindowState == FormWindowState.Minimized)
            {
                Hide();
                notifyIcon1.Visible = true;
                System.Threading.Thread.Sleep(2000);
                notifyIcon1.ShowBalloonTip(5000);
            }
        }

        private void notifyIcon1_MouseClick(object sender, MouseEventArgs e)
        {
            ActivateMainWindow();
        }

        private void notifyIcon1_BalloonTipClicked(object sender, EventArgs e)
        {
            ActivateMainWindow();
        }

        private void Form1_Activated(object sender, EventArgs e)
        {
            textBox1.Text = textBox1.Text + " " + DateTime.Now + " - " + this.Name + " activated\r\n";
        }

        private void Form1_Deactivate(object sender, EventArgs e)
        {
            textBox1.Text = textBox1.Text + " " + DateTime.Now + " - " + this.Name + " deactivated\r\n";
        }

        private void ActivateMainWindow()
        {
            Show();
            this.WindowState = FormWindowState.Normal;
            notifyIcon1.Visible = false;
        }
    }

As expected, clicking the notification that is shown when calling ShowBalloonTip() does activate the window, which illustrates that the intended behavior is definitely possible.

Digging deeper it seems that the issue might specifically be:

mumble/src/mumble/MainWindow.cpp

Line 3501 in 74faaba

setWindowState((windowState() & ~Qt::WindowMinimized) | Qt::WindowActive);

If you disable the option of hiding Mumble to the system tray when minimized, minimize Mumble then clicking on a notification, Mumble restores itself and is now the top-most window (even if it's still not activated). Definitely better than before because at least now the main Mumble window is in the foreground.

I don't have a C++ compiler handy to test but I feel like showRaiseWindow needs some minor modifications, maybe something along the lines of:

void MainWindow::showRaiseWindow() {
	show();
        // don't need a conditional check for being minimized since we're always removing the Qt::WindowMinimized flag
	setWindowState((windowState() & ~Qt::WindowMinimized) | Qt::WindowActive);
	raise();
	activateWindow();
}

That should hopefully:

1. Restore from system tray
2. Remove the Minimized window state
3. Set the Active window state
4. Set the window to be the top-most window (foreground)
5. Activate the window

[Krzmbrzl]

I'm afraid that messing with the minimize to tray feature in any way will become an enormous undertaking in and of itself as this is a complete mess that tends to create infinite loops and whatnot 👀

It might be worth a try though

[Snowknight26]

I gave this a shot a couple weeks ago, using some ideas from other programs that use the Qt framework and correctly bring a window to focus, but didn't have any luck solely changing what showRaiseWindow does. I wonder if a handle to the foreground process/window that triggered the notification isn't being passed properly somehow. Might have to look into how and which Mumble windows create the notification.

More reading:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow

[Hartmnt]

Hi,

I investigated this in #6466 and there are three issues here:

1. The notification event on messageClicked is buggy in Qt in general https://bugreports.qt.io/browse/QTBUG-87329
2. This thread talks about "de-minimaziation" aka "restoring" a window and "giving focus to a window" aka "activating the window" somewhat confusingly.

and most importantly

3. As written in the linked Qt documentation of activateWindow above: It is simply a limitation of the Windows compositor/window manager to not allow applications to steal focus. This is a deliberate decision of Microsoft and honored by Qt (Qt probably has no choice in this, as Windows will unlikely provide an API for something they do not want applications to do). We have no way to work around this either. The reason this might work for other applications / in some scenarios is stated in https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow

Additionally, at least one of the following conditions is true:
    The calling process is the foreground process.
    The calling process was started by the foreground process.
    There is currently no foreground window, and thus no foreground process.
    The calling process received the last input event.
    Either the foreground process or the calling process is being debugged.

Meaning that if there is no foreground window (focus on the desktop maybe?) this might work etc.

---

Anyway, in #6466 I modified the showRaiseWindow function and fixed the tray behavior in general. Which means that I believe that Mumble should at least be correctly restored from minimization now. If you are still using Mumble and are willing to test the changes to the tray icon, I would be very glad. I need some Windows users to test this.

However, the issue as stated here (no focus on notification click) can not be fixed by us and would require a change in the Windows compositor/window manager.

[Snowknight26]

If you are still using Mumble and are willing to test the changes to the tray icon, I would be very glad. I need some Windows users to test this.

Every day. 😉 Happy to test.

[Hartmnt]

@Snowknight26 That would be really great!

This is a Mumble Windows build created by our CI pipeline:
https://dev.azure.com/Mumble-VoIP/c819eb06-7b22-4ef3-bbcd-860094454eb3/_apis/build/builds/8469/artifacts?artifactName=Windows%20%28x64%29%20installer&api-version=7.1&%24format=zip

I assume you are currently using 1.5.634, which means there should be no problem in upgrading to the test build. If you are coming from 1.4.x you might want to backup your settings file before upgrading in case the experimental build breaks something, because the settings will be migrated to a JSON file from 1.4 -> 1.5.

Please check, if the tray icon behaves "as correct as possible" in this experimental build 😅 I have also added a few questions to the bottom of #6466 which should ideally all be answered with "yes"