Repository navigation
e2e: choice-builder-pages-phone fails since #2215 (row never holds still after reload) #2218
Description
tests/e2e/choice-builder-pages-phone.test.ts fails on current master in a native run on macOS (Obsidian 1.14.3, isolated worktree instance). The test that fails is "keeps the focused field and its suggestions above the keyboard, under a header that stays solid":
WaitForTimeoutError: Timed out waiting for [aria-label="More options for Phone macro"] visible and still after 10000ms.
❯ clickWhenStill tests/e2e/uiHelpers.ts
❯ openChoicePage tests/e2e/choice-builder-pages-phone.test.ts:77:2
❯ openMacroPage tests/e2e/choice-builder-pages-phone.test.ts:54:2
Bisect
The spec files and the instance stayed the same throughout. Only main.js changed, built from src at each commit:
src at |
Runs | Failed |
|---|---|---|
| eaa72c8 (before #2215) | 3 | 0 |
| 40dd5b4 (#2215) | 3 | 2 |
| 65dcf2f (#2216) | 1 | 1 |
| 2abd73c (master) | 5 | 5 |
Running master's own tests/e2e against the master build also fails 3 of 3.
What I know
The step that fails comes after plugin.data().patch() and plugin.reload(). The row's "More options" button exists, but its position does not hold still across two samples 100ms apart for 10s. #2215 makes an unloaded instance add and remove no choice commands. It also drops a settings read that lands after unload. I have not confirmed which of these interacts with the reload here. Whether a user can hit this outside the harness is also unconfirmed.
Found while verifying the e2e fixes in #2217.
Activity
chhoumann commentedon Oct 9, 2026
It does not reproduce on Linux. The phone spec passed in all 13 runs below, against master at e772433. Each run used
.agents/run-e2eon an isolated worktree instance.data.jsonraw events delayed by 0, 100, 300, 600, 1000, and 2000 msThe host load average was about 48 on 12 cores, so CPU contention does not trigger it here.
The bisect needs a failing baseline, so I skipped it. The probe logged each reload and sampled the row every 50 ms. The "More options" button held still at the same point from the moment the row appeared until the click.
What differs from the macOS runs
onExternalSettingsChange()on adata.jsonwrite (debounced 50 ms, gated on mtime), then callssettingTab.update(). Delayed events alone did not cause the failure.What would settle it
The current message conflates three states, so it cannot tell us which one macOS hits. #2219 makes
clickWhenStillend its timeout with the last two samples:"absent","hidden", or the button's center. One macOS run with #2219 shows which state it is:"hidden", "hidden"means the row rendered but the phone settings view never showed the tab. That points at the open/retry loop inopenChoicePage."absent"means the tab content was torn down after the row check passed.test(e2e): report what clickWhenStill last saw when it times out (#2219)
chhoumann commentedon Oct 9, 2026
Reopened. #2219 closed this by accident: its body said "does not fix #2218", which GitHub parses as a closing keyword. #2219 only adds diagnostics. The macOS failure still needs one run with it to show whether the row is absent, hidden, or moving.