Cumulus
Cumulus copied to clipboard
gillesdemey
Window under the taskbar
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.
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. :)
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.
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.
Should I file that bug on menubar's repo? Edit: let's scratch that, I'll do some tests with a dummy app first.
@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.
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
-
ScreenToDIPRectdoes not calculate the click bounds correctly, in which case commit 324153d on Electron might have caused the issue (even though it should prevent it).