-
-
Notifications
You must be signed in to change notification settings - Fork 998
fix: bottom overlay positioned partially off-screen #543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
VirenMohindra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work!
| OverlayPosition::Bottom | OverlayPosition::None => { | ||
| // don't subtract the overlay height it puts it too far up | ||
| work_area_y + work_area_height - OVERLAY_BOTTOM_OFFSET | ||
| work_area_y + work_area_height - OVERLAY_HEIGHT - OVERLAY_BOTTOM_OFFSET |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how does this look on windows / linux?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking a look. Unfortunately, I don’t have access to either.
|
I can ping other folks to test but we might be able to just feature flag this off for MacOS or something |
|
@antons I'm curious if we can do any kind of dock detection logic or even get system information from the dock height because I suspect that this doesn't work properly across all systems and screens. Mainly because you can change the dock height itself, and this is just a constant currently. At least in my case, I have the dock automatically hiding and when it's showing again I still have the overlap with the overlay being on the dock as well, which is not ideal.
Possibly this is something we could do via |
|
Nice fix! This resolves a real issue with auto-hiding Dock — the overlay now stays fully on-screen without clipping. Personally prefer subtracting overlay height from position calculation, aligns with HIG. 👍 |
|
@cjpais I haven’t looked into the code on the Dock height, but tried resizing the always-visible Dock just now and the overlay seems to correctly position itself outside the Dock no matter what size it is. For auto-hiding Dock, animating the overlay to get out of the way in case the Dock appears is probably possible. I see this as low priority, because I almost never switch apps while actively recording. |
|
@antons oh interesting I will have to try this PR again, it did not work nicely for me when I tried on my machine |
|
im going to review this again in the next few days probably, also curious if tauri_plugin_positioner may help |
|
@borzov @VirenMohindra @antons for whatever reason on my machine the behavior seems correct without the fix, and with the fix makes it place more awkward. Without the fix the behavior is not like this for you? This is how it is for me without the fix
|
|
@cjpais I’ve been experiencing this bug, as shown on my screenshots, consistently on two different Macs with macOS 26.3 betas and RC. Maybe on macOS 26.2 before that, but I’m not sure. Both Macs (mini and Studio) connected to a single external screen. Seems like there is a difference in either software or hardware configuration that causes this. |
|
Interesting thanks for sharing more details |
|
I have also now tried showing the menu bar (normally I have it automatically hidden), and changing screen scaling to match native pixel size, 2x retina, and then smaller scaled, and couldn’t get the overlay to render in a different way. |
This commit reverts a change from 0068b6b which caused overlay to be shown partially off-screen when enabling System Settings > Desktop & Dock > Automatically hide and show the Dock.
d9f1668 to
57a03da
Compare
|
@cjpais After more testing and another round of investigation, I can reliably reproduce this bug when the menu bar is set to be automatically hidden in System Settings. A full fix needs both:
I pushed a temporary Tauri crate override for you to test. That Tauri PR has been open for a while with no recent activity. I’m new to Tauri, and I’m not sure what is the best way to proceed. Handy’s own fork of Tauri? |
|
@antons thanks for this, it works great on my system as well now. Let me know if with my fork everything works as expected for you. I'll merge it, I also kicked off a test build for this PR just to make sure CI and everything works fine I posted a comment there just showing support for that PR, hopefully it will be merged |
🧪 Test Build ReadyBuild artifacts for PR #543 are available for testing. Download artifacts from workflow run Artifacts expire after 30 days. |
|
@cjpais Tested. Looks good to me! |
|
Awesome thank you! Merged |


Before Submitting This PR
Please confirm you have done the following:
Human Written Description
This commit reverts a change from 0068b6b which caused overlay to be shown partially off-screen when enabling System Settings > Desktop & Dock > Automatically hide and show the Dock.
The commit that introduced this issue added a comment “don't subtract the overlay height it puts it too far up”. I’m not a fan of overlapping the Dock, but this is subjective. I can amend the PR to keep the overlay position as is when the Dock is visible.
Before with the Dock hidden
After with the Dock hidden
Before
After
Wispr Flow