Open OlJohnny opened 3 months ago
Hi there,
Thank you for your report!
I was able to reproduce this issue, and I have flagged this to our engineering team.
If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time - our engineering team will be happy to review these.
Thanks once again!
I have created a PR with a simple offset for windows plattforms
This probably isn't the "correct" solution, but is a working solution until this issue is fixed upstream in Electron.
Steps To Reproduce
note: as i can only test this on windows, i can only confirm this behaviour on windows
Expected Result
the app should remember the position and bounds of the window exactly and should assume that position and bounds upon restart (as long as the same monitor is still connected, and the app doesn't step over screen bounds)
Actual Result
the right edge of the app window gets pushed to the left by roughly 24px, thus the expected result is broken
Screenshots or Videos
setting the position and bounds
after restart of app
Additional Context
The currently used method
getBounds()
represents the window size including the app window title bar and borders. However on Windows (10,11) this includes the "old" 8 pixel wide border (on the sides and bottom) known from windows 7, which in practice only displays as a 1 pixel wide border. Ergo we have a 7 pixel wide "invisible" border on the left, bottom and right. see here for referenceThis info can bee seen using WindowSpy from AutoHotKey. Notice the screen width is 16 pixels larger than the client width, even though we can see that the window is filling the whole width (see screenshot below)
When we are calculating if a window is stepping over screen bounds and we are using
getBounds()
, we think a window is stepping over, even though it doesn't look like it (-> the invisible border).Operating System
Windows
Operating System Version
No response
Installation method
Direct Download (from bitwarden.com)
Build Version
2024.6.4
Issue Tracking Info