Skip to content

[Barr] Investigate macOS 26 NSStatusBarWindow layout recursion warning #2

Description

@zackbart

Migrated from zackbart/barr#8 during the native-app monorepo consolidation. Originally opened 2026-07-28.

Summary

On macOS 26, Barr intermittently logs an AppKit layout-recursion warning while the system updates its remotely hosted status-item scene:

It is not legal to call layoutSubtreeIfNeeded on a view which is already being laid out.

The process remains alive and no user-visible crash has been observed, but AppKit warns that this behavior may break in the future.

Reproduction

  1. Launch Barr on macOS 26.
  2. Inspect the unified log for NSDetectedLayoutRecursion or layoutSubtreeIfNeeded.
  3. Repeat cold launches; local disposable-build testing reproduced the warning on multiple launches, including with only one Barr process running.

Observed against Barr 0.0.8.

Debugging evidence

Breaking on _NSDetectedLayoutRecursion in LLDB stopped on the main thread with this AppKit view hierarchy:

  • NSStatusBarWindow
  • NSStatusBarContentView
  • NSNextStepFrame

The stack entered through a FrontBoardServices scene-settings update and AppKit window placement/layout. It contained no Barr shelf or custom view frame above the application run loop.

Additional checks already performed:

  • Removed duplicate Barr Debug processes before reproducing.
  • Used a fixed-width release status control.
  • Deferred creation of the SwiftUI shelf until it is needed.
  • Confirmed repeated launches survive the warning.
  • A small standalone status-item script did not reproduce it, so the exact Barr status-item/autosave sequence likely matters.

Investigation ideas

  • Reduce configureStatusItems() to a standalone reproduction using the same two autosave names and preferred-position values.
  • Determine whether creating the control and storage anchor in separate settled scene updates avoids the re-entry.
  • Test whether forcing preferred-position defaults on every launch contributes to the remote frame update.
  • Compare normal signed release launches with ad-hoc disposable builds.

Acceptance criteria

  • Twenty consecutive cold launches on macOS 26 without the AppKit warning.
  • The visible Barr control remains reachable across relaunches and notched displays.
  • Persisted items still restore and park correctly.
  • Existing CI and menu-bar geometry tests remain green.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions