base red: ClickedLinkFocusTests' pane on the right holds a browser, so a link lands there on any host

Merged
LA
6d ago
+34-13

Summary

Base red: three ClickedLinkFocusTests fail on some fleet hosts. The failing tests are aLinksTabInAnotherPaneTakesTheFocusAndItsCloseKeepsItInThatPane, theSameLinkClickedAgainSelectsItsTabOnTheRight and aChatChipClickedAgainSelectsItsTabOnTheRight.

No commit in 79e9919c5c5..b6eb84916c1a caused this. The good end of the range, 79e9919c5c5, fails in the same way on cmux13s-Mac-mini (job 479ab2586f0c). The earlier pass at f68598505915 (serial job 54e4c583d660) ran on a different host, cmuxs-Mac-mini. So the result depends on the host, not on a commit.

Cause: the test fixture depends on a rule that uses pane widths. In each test, the pane on the right holds only the split's terminal. Since #28989 (RightColumnPlacement.decide), a web link opened beside a pane with only a terminal goes to one of two places:

  • A new split below that pane, when the source is 480 pt or wider and the right pane is 420 pt or wider. A width that is not measured (LinkOpener.width(of:) is nil while the pane view has no window) sets no limit, so this case also gives a split.
  • A tab in that pane, when a pane is narrower.

On cmux13 the link split below. The red log shows the link's tab alone in a third pane. At the tip, the check at line 75 saw the tab for a short time while it moved through the right pane to the new split. The close then emptied that split and gave the focus back to the source, so the test failed at line 87.

Fix (test only): a new helper, splitRightHoldingABrowser, makes the pane on the right hold one browser tab and no terminal. Since #29684 (the same-kind rule), a browser link goes to a pane that already holds a browser, at any width. So the link now lands in the pane on the right on every host. Every assertion is unchanged. The timeout reports now also print each pane's width.

Owner: plans/cmux-next/OWNERS.md has no row for ClickedLinkFocusTests or for LinkOpener/RightColumnPlacement, so this goes to the Performance Lead. The placement rule is Leo's (#28989, #29684); this PR does not change it.

Testing

cmux-ci run --class light --display --target-worker <host> --script scripts/ci/package-test-lane.sh --arg=suite --arg=Packages/macOS/CmuxNext --arg=ClickedLinkFocusTests --env CMUX_TEST_REQUIRE_GUI=1 (the whole suite)

  • Red at the range's good end, 79e9919c5c5, on cmux13s-Mac-mini: job 479ab2586f0c. The three tests fail at lines 74, 120 and 156.
  • Red at the base, 40c945f9ec2, on cmux13s-Mac-mini: job 9f9d7ca8b712. The tests fail at line 87 (aLinksTab) and line 149 (chip).
  • Red at b6eb84916c1a on cmux13s-Mac-mini: job f0257e33578004bf6ed3fab1. The tests fail at lines 75, 121 and 149.
  • Green at the head, 29861047b438, on cmux13s-Mac-mini: job f402232e041d. The three tests pass.
  • Green at the head, 29861047b438, on cmuxs-Mac-mini: job 66a2197d4226acd37c3a7898. The three tests pass. An earlier attempt, job 64504ef3f7a5, was cancelled by the fleet ("context canceled").

Observed / Not run

  • Observed: in every run of this suite on both hosts, including the serial run 54e4c583d660, anAgentsOpenFromALoneChatRefocusesTheChatAsTheApp also fails at line 256. This is a separate failure and this PR does not fix it. Because of it, the suite still exits 1.
  • Not run: a direct measurement of why the hosts differ. The new width output shows panes 440 pt wide on both hosts, which is narrower than the split limit. So the window is not wider on cmux13. The most likely cause of the split there is a width that was not yet measured (a pane view with no window yet), which sets no limit. This depends on timing. I read this from the code; I did not prove it with a separate run. The fix does not depend on which of the two causes it is.

Changelog

none