Skip to content

fix(menubar): fall back to Thaw Bar when hiding app menus under fullscreen#741

Open
auspic7 wants to merge 1 commit into
stonerl:mainfrom
auspic7:fix/fullscreen-hide-app-menus
Open

fix(menubar): fall back to Thaw Bar when hiding app menus under fullscreen#741
auspic7 wants to merge 1 commit into
stonerl:mainfrom
auspic7:fix/fullscreen-hide-app-menus

Conversation

@auspic7

@auspic7 auspic7 commented Jun 23, 2026

Copy link
Copy Markdown

What does this PR do?

Adds a fullscreen guard to the synchronous "hide application menus" path in MenuBarSection.show(), mirroring the guard already present in the reactive sink in MenuBarManager. When a fullscreen space is active and the hidden section would otherwise be presented via .inlineHidingApplicationMenus, it now falls back to .iceBar (the Thaw Bar panel) instead.

PR Type

  • Bugfix
  • CI/CD related changes
  • Code style update (formatting, renaming)
  • Documentation
  • Feature
  • Refactor
  • Performance improvement
  • Test addition or update
  • Other (please describe):

Does this PR introduce a breaking change?

  • Yes
  • No

Why

Activating an app inside a fullscreen space makes macOS immediately hide the menu bar — the platform behavior reported as Apple Feedback FB13544993 ("Menu bar should not hide when in fullscreen space and a LSUIElement/accessory app is activated").

Hiding application menus requires hideApplicationMenus()appState.activate(withPolicy: .regular)NSApp.activate(ignoringOtherApps: true). The reactive code path already guards against running this under fullscreen:

// MenuBarManager.swift
guard
    appState.settings.advanced.hideApplicationMenus,
    ...
    !appState.activeSpace.isFullscreen,   // ← guarded
    ...

…But the synchronous path driven by a click (ControlItem.performAction()section.toggle()section.show()presentationMode(on:).inlineHidingApplicationMenushideApplicationMenus()) had no such guard, so the activation ran even under a fullscreen space and the menu bar disappeared.

Since Defaults.DefaultValue.hideApplicationMenus = true, this reproduced on a fresh install whenever a user clicked the control item while another app was fullscreen.

What's new

In MenuBarSection.show(), after computing presentationMode(on:), if the result is .inlineHidingApplicationMenus and appState.activeSpace.isFullscreen is true, downgrade to .iceBar. The Thaw Bar panel is shown via orderFrontRegardless() and does not activate the app, so the platform issue is avoided. Non-fullscreen behavior is unchanged.

This is the same guard the reactive sink uses, just applied to the click-driven path.

Issue Number: #740

How I tested

  • Built successfully (xcodebuild ... build, Swift 6.3.2 / Xcode 26.5, macOS 26.5.1).
  • Manually reproduced the bug on the unpatched build (menu bar hides when clicking the control item under a fullscreen app with the default setting), and confirmed the menu bar stays visible on the patched build (section expands via the Thaw Bar under fullscreen, and still expands inline by hiding app menus on a normal desktop space).

I could not find an existing unit/synthetic test covering this code path; happy to add one if maintainers point me at the preferred test target/fixture.

Summary by CodeRabbit

  • Bug Fixes
    • Enhanced menu bar display handling in fullscreen mode. When using hotkeys to access the menu bar during fullscreen active spaces, the application now intelligently adjusts its presentation to ensure application menus remain visible and accessible. This prevents display conflicts that could otherwise hide critical menu functionality.

…creen

Activating Thaw to hide application menus inside a fullscreen space makes
macOS immediately hide the menu bar (FB13544993). The reactive sink in
MenuBarManager already guards against this, but the synchronous path
through MenuBarSection.show() -> presentationMode -> hideApplicationMenus()
did not. Mirror the existing isFullscreen guard there: when a fullscreen
space is active and the section would otherwise use inlineHidingApplicationMenus,
fall back to the Thaw Bar, which is shown via orderFrontRegardless() and
does not activate the app.

The HideAppMenus setting is on by default, so this reproduced on fresh
installs.

Fixes stonerl#740.
@coderabbitai

coderabbitai Bot commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2a8422ba-707e-4190-a0af-f6fc6293d014

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • ✅ Review completed - (🔄 Check again to review again)
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the bug Something isn't working label Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant