Skip to content

Fix Editor preferences pane hang in wrapping-checkbox layout test - #568

Merged
schuyler merged 1 commit into
mainfrom
claude/test-workflow-loops-493-h4d1o5
Aug 12, 2026
Merged

Fix Editor preferences pane hang in wrapping-checkbox layout test#568
schuyler merged 1 commit into
mainfrom
claude/test-workflow-loops-493-h4d1o5

Conversation

@schuyler

Copy link
Copy Markdown
Owner

Summary

  • The Editor preferences pane's "Behavior" NSBox positioned its checkboxes relative to the box's content view instead of the box itself, unlike every other box in the preferences panes (General, Markdown). The content view had no constraints of its own tying it to the box, so the box's height had no required-priority path back to its checkboxes' actual size.
  • +[MPPreferencesViewController addHeightConstraintsForWrappingCheckboxesInView:] grows checkboxes past their default height when their titles wrap, and in that state layoutSubtreeIfNeeded never converges for this box. MacDownTests/MPPreferencesViewControllerResizabilityTests.m's testWrappingCheckboxHeightsAccommodateMultiLineText exercises exactly this by forcing wrapped titles, and hangs CI indefinitely as a result (observed on PR Add folder workspaces: hideable sidebar + native tabs + macdown . #493, unrelated to that PR's diff — this bug is pre-existing on main).
  • The four affected constraints in MPEditorPreferencesViewController.xib now reference the box instead of the content view, matching the General and Markdown panes' boxes. The constants are adjusted for the box's chrome inset (1pt left/right/bottom, 15pt top), so the checkboxes' resolved position and the box's total height are unchanged — verified algebraically against the box/content-view frame deltas, not just asserted.
  • Also adds a 30-minute job/step timeout and -test-timeouts-enabled YES -maximum-test-execution-time-allowance 120 to the xcodebuild test invocations in test.yml and release.yml's "Run tests before release" step, which lacked them — matching the existing convention already used in smoke-test.yml and release.yml's UI-test step. This bounds any future test hang to minutes instead of GitHub's 6-hour default, independent of whether this particular fix is complete.

Verification

  • Root cause and fix were each independently reviewed by a separate agent (design review before implementation, full-branch implementation review after) per this repo's review process.
  • XML well-formedness and constraint-graph completeness verified programmatically.
  • Geometry preservation (checkbox position, box height) verified algebraically from the box/content-view frame deltas — not run, since this environment has no macOS/Xcode.
  • Not yet visually verified on macOS. The math says nothing should move, but a human should eyeball the Editor preferences pane (English and one wrapping locale) before merge.

Test plan

  • CI passes on both macos-14 and macos-26 without hanging
  • Manually open Preferences → Editor on macOS and confirm the "Behavior" box's checkboxes are laid out correctly (no clipping, no unexpected shift)
  • Same check with a long-title locale (e.g. French) if convenient, since that's the scenario the checkbox-wrapping code exists for

Generated by Claude Code

The Editor pane's "Behavior" NSBox positioned its checkboxes relative
to the box's content view instead of the box itself, unlike every
other box in the preferences panes. The content view had no
constraints of its own tying it to the box, so the box's height had
no required-priority path back to its checkboxes' actual size.
addHeightConstraintsForWrappingCheckboxesInView: grows those
checkboxes past their default height, and layoutSubtreeIfNeeded never
converges — CI's testWrappingCheckboxHeightsAccommodateMultiLineText
hung indefinitely as a result.

The four affected constraints now reference the box instead of the
content view, matching the General and Markdown panes' boxes. The
constants are adjusted for the box's chrome inset (1pt left/right/
bottom, 15pt top) so the checkboxes' resolved position and the box's
total height are unchanged.

Also add a 30-minute job/step timeout and
-test-timeouts-enabled/-maximum-test-execution-time-allowance to the
xcodebuild test invocations in test.yml and release.yml that lacked
them, matching the existing convention in smoke-test.yml and
release.yml's UI-test step. This bounds any future test hang to
minutes instead of GitHub's 6-hour default.

Related to #493

schuyler commented Aug 12, 2026

Copy link
Copy Markdown
Owner Author

CI update: the fix works — Run Unit Tests (macos-14) (the job that hung on PR #493) now completes in ~2 minutes with no hang, and Verify Release Build (Dry Run) passed.

Run Unit Tests (macos-26) failed, but not from a hang or timeout — it ran the full 397-test suite normally and failed on one test: -[MPResourceWatcherSetTests testDelegateCalledOnAtomicSave]. That test is a wall-clock race (dispatch_after 0.1s, then waitForExpectationsWithTimeout:2.0) in the file-watching code (MPResourceWatcherSet), last touched by an unrelated commit (2f62a58, issue #478) — nothing this PR changes. It's the kind of test that can flake under CI load rather than a real regression.

@schuyler
schuyler merged commit d3dc8ea into main Aug 12, 2026
4 of 5 checks passed
@schuyler
schuyler deleted the claude/test-workflow-loops-493-h4d1o5 branch August 12, 2026 13:19
@schuyler schuyler added the rc-pending Included in a release candidate awaiting validation label Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rc-pending Included in a release candidate awaiting validation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants