Skip to content

Conversation

@antons
Copy link
Contributor

@antons antons commented Jan 6, 2026

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

before-crop

After with the Dock hidden

after-crop

Before

dock-before-crop

After

dock-after-crop

Wispr Flow

flow-crop

Copy link
Contributor

@VirenMohindra VirenMohindra left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@cjpais
Copy link
Owner

cjpais commented Jan 8, 2026

I can ping other folks to test but we might be able to just feature flag this off for MacOS or something

@cjpais
Copy link
Owner

cjpais commented Jan 10, 2026

@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.

Screenshot 2026-01-10 at 11 04 56 AM

Possibly this is something we could do via objc2 if not exposed nicely through Tauri?

@borzov
Copy link

borzov commented Jan 18, 2026

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. 👍

@antons
Copy link
Contributor Author

antons commented Jan 18, 2026

@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.

@cjpais
Copy link
Owner

cjpais commented Jan 18, 2026

@antons oh interesting I will have to try this PR again, it did not work nicely for me when I tried on my machine

@cjpais
Copy link
Owner

cjpais commented Feb 1, 2026

im going to review this again in the next few days probably, also curious if tauri_plugin_positioner may help

@cjpais
Copy link
Owner

cjpais commented Feb 6, 2026

@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

Screenshot 2026-02-06 at 4 53 09 PM

@antons
Copy link
Contributor Author

antons commented Feb 6, 2026

@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.

@cjpais
Copy link
Owner

cjpais commented Feb 6, 2026

Interesting thanks for sharing more details

@antons
Copy link
Contributor Author

antons commented Feb 6, 2026

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.
@antons antons force-pushed the fix/overlay-bottom-position branch from d9f1668 to 57a03da Compare February 8, 2026 17:01
@antons
Copy link
Contributor Author

antons commented Feb 8, 2026

@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:

  1. this PR
  2. the fix for a Tauri bug that already has an open PR at fix(macOS): correct value for work_area.position.y tauri-apps/tauri#14655.

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?

@cjpais
Copy link
Owner

cjpais commented Feb 9, 2026

@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

@github-actions
Copy link

github-actions bot commented Feb 9, 2026

🧪 Test Build Ready

Build artifacts for PR #543 are available for testing.

Download artifacts from workflow run

Artifacts expire after 30 days.

@antons
Copy link
Contributor Author

antons commented Feb 9, 2026

@cjpais Tested. Looks good to me!

@cjpais
Copy link
Owner

cjpais commented Feb 9, 2026

Awesome thank you! Merged

@cjpais cjpais merged commit a9024d0 into cjpais:main Feb 9, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants