electron: `window.alwaysOnTop` no longer work in Electron v7 (alwaysOnTop broken)

I was able to reproduce this and at least work around it on Windows by supplying the window.setAlwaysOnTop(true, "normal")

It looks like it defaults to "floating" which runs it through MoveBehindTaskBarIfNeeded(). Hope that helps.

Confirmed still broken in v7, v8 and v9 as of this post. v6 does work.

I can verify that I am successfully using window.setAlwaysOnTop(true, FLAG) instead of window.setAlwaysOnTop(true)

I wrote a small fiddle to add to the number of reproductions. I hope it proves useful 😃

Using this we managed to see stuff similar to what’s been described in this thread. What we did specifically, was

• Run the above app
• Enable “Always on top” in the menu
• Take some youtube video and “fullscreen” it
• Drag the little Electron app to the same screen as the video, if it’s not there already. The app should be on top, and the video in the background.
• Mouse-click on the video in the background. The app should remain on top.
• The “break” happens as we mouse-click the Electron app again
  • On v6.1.12, it just gets focus and we can interact with it again
  • On v7.0.0, it disappears behind the youtube video

“Alt-tabbing” between the windows seems to have worked fine for us though, which seems to contradict some of @Slapbox 's observations unfortunately!

So, it seems that it is exactly in v7.0.0 something bad happens in this regard. The only seemingly relevant change I can spot there is https://github.com/electron/electron/pull/19462.

alwaysOnTop used to display over virtual machine windows even when they were in fullscreen, but it no longer does.

Can confirm! This is the case that’s driving our wanting to fix this.

I am almost certain that no one is working on this @KraftyKraft. I’m honestly not sure how tickets are prioritized for Electron but the process seems to be broken.

Please reopen

@Slapbox Windows 11

Also seeing it with VMWare and Citrix Thin client, any workaround that is known to work at this moment?

I’ll see what I can do. Thanks @ckerr.

Hey @lacymorrow, thanks for opening the other issue. I think that is a question that the Electron team will need to collectively decide on; but for the specifics of linking back to this issue, I appreciate the re-ping.

It looks like this issue predates when the team started using gists + electron-fiddle to triage bug reports. Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use. Because of time constraints, debugging code with third-party dependencies is usually not feasible for a small team like Electron’s.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone’s looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

I’m adding the blocked/needs-repro label for this reason. After you make a test case, please link to it in a followup comment.

Thanks in advance! Your help is appreciated.

confirming the issue

window.isAlwaysOnTop returns false after window.setAlwaysOnTop(true) executes in next conditions:

1. open any game in borderless windowed mode
2. open BrowserWindow with options: alwaysOnTop, transparent, no frame
3. focus on game (BrowserWindow still stays on top)
4. alt+tab to BrowserWindow
5. click back to game
6. BrowserWindow disappears with no possibility to successfully execute window.setAlwaysOnTop(true)

electron 7.0.1 - doesn’t work electron 6.1.4 - no issues

We’ve tried it out now, using the fiddle I posted above, and going trough those reproduction steps again. And we can confirm it works for us too! More specifically, the flags normal, pop-up-menu och screen-saver seem to work well on Windows. OSX behaved a little bit differently (normal was not helpful e.g.), but we don’t expect any trouble there.

@benleachrp @Slapbox Very cool, I’ll see if I can try it out soon!

Awesome addition to getting this resolved @KraftyKraft!

I just played around a bit more and specifically this is what triggers the alt+tab issue, and it does so pretty consistently for us. You might need to try a few times even so though. We’re seeing this with Electron@8.5.5 running on Windows 7, and any fullscreen VMware Player window. I wonder if you can reproduce using these steps?

1. Enable alwaysOnTop in your app on the host machine
2. Jump into a fullscreen virtual machine
3. For VMware Player, Ctrl+Alt to unfocus the current virtual machine so hotkeys will go to the host OS
4. Alt+Tab to your app, nothing happens (for us at least)
5. Alt+Tab to your app again, now the app will stay on top of the virtual machine until it is clicked.
6. After clicking the app, clicking back into the virtual machine and the app will fail to appear on top

I noticed that at least once when the Alt+Tab out to our app failed, the window actually did flash into view for a tiny fraction of a second before it disappears. In this case, the taskbar icon for our app remains lit, so the OS seems to think that the app is focused properly. Upon clicking the taskbar icon, the OS returns focus to where it was previously (in this case our VM) which further indicates that the OS thinks the app is focused.

I’ve noticed the same, in Electron 8.5.x. I’ll have to come back to update this when we upgrade to a newer version. Here are my findings:

At first I thought it was some change on my end, but I’m definitely seeing alwaysOnTop not function as intended on Windows.

The issue seems especially likely to occur after swapping out of some fullscreen window, like a virtual machine. After doing this, it seems like the window can only stay on top in one of four scenarios:

alwaysOnTop works when:

• The user clicks a background window to activate it

alwaysOnTop fails when:

• The user uses <kbd>Alt+Tab</kbd> to activate the background window
• The user uses <kbd>Win+Tab</kbd> to activate the background window
• The user clicks the taskbar icon for the background window to activate it

Additionally:

• alwaysOnTop used to display over virtual machine windows even when they were in fullscreen, but it no longer does.

• If I <kbd>Alt+Tab</kbd> out of the fullscreen window and try to land on our app, sometimes the app switcher will not actually focus the app. Instead, the app moves to a further position in the app-switcher and requires you to try again. This seems to be directly related to the issue but doesn’t always occur.

• When it does switch to the app properly (which it does more often than not), then there’s seemingly a 50/50 chance that you’ll end up in the broken state I outlined above, where 3 of 4 methods of activating a background window result in hiding of the Electron window. BUT it doesn’t seem to be a true 50/50 chance, but rather a toggling situation. This makes me wonder if the issue is due to some piece of Electron’s window management state going out of sync with the OS?

Confirmed still broken in v9.3, v10.1.1. Works on v6.

fwiw I was encountering similar issues with a window not working properly when on AlwaysOnTop mode, in fact opening that window was affecting another “on-top” window that would otherwise work fine. The fix in my case was to reduce the height by one pixel, the initial bounds where covering the whole display, subtracting a single pixel from its height solved all problems 🤷

This is still a problem with 7.1.14