Window under the taskbar

[theCyanEYED]

This issue happens under Windows 10, after locking and unlocking a session. The options button is still reachable, that's how I can close and restart the app.

[MichielDeMey]

Hi! Thanks for the bug report.
We currently do not yet support Windows mostly due to issues like these, and unfortunately we rely on a third-party library when it comes to the positioning of the window based on the task bar.

Nonetheless, we'll keep this ticket open for future reference. :)

[seppestas]

Hey @theCyanEYED, do you have your Windows taskbar set to auto-hide?

[theCyanEYED]

The taskbar is fixed. However I have two screens and one of them takes longer to wake up, sometimes that messes with my window layouts when I log back in (i.e. all windows moved to the main & slowest monitor). I don't know if that could be a cause.

[seppestas]

Mmmh, if that's the case, it's probably an issue caused by Windows. Electron retrieves the location of the icon when the click event is triggered, and afaik menubar re-computes the window location based on the information it gets from Electron every time the click event gets received.

I'll try to come up with a way to test this when I find some time.

[theCyanEYED]

Should I file that bug on menubar's repo?
Edit: let's scratch that, I'll do some tests with a dummy app first.

[seppestas]

@theCyanEYED I think this is a Windows bug. If you can reproduce this bug on other electron apps it might make sense to report it to the Electron project and/or the Chromium project (issue tracker).

Anyhow, this bug is caused either by Window's Shell_NotifyIconGetRect function reporting an incorrect location of the notification icon or something in the Cumulus - Menubar - Electron - Brightray - libchromiumcontent - Chromium chain caching old values. As far as I can see the click bounds do not get cached anywhere, so I think this is a Windows issue.

[seppestas]

Wait a minute: this issue could also be caused by the DPI scaling of the monitors being different. In that case I can come up with a couple of scenarios that could cause this issue:

• The window height calculation does not take the new DPI scaling in account, causing the window to be incorrectly placed
• ScreenToDIPRect does not calculate the click bounds correctly, in which case commit 324153d on Electron might have caused the issue (even though it should prevent it).