Prove a click on a pixel runs the handler, with a real mouse

[kellylford]

The mouse work shipped with its logic under test and its wiring asserted by reading MainWindow's source as text. Neither can answer the question the folder bug (#601) actually turned on: does a click on that pixel end up running that handler? Every piece there was correct and clicking a folder still did nothing.

What this adds

MouseClickInputTests sends real SendInput clicks at real screen coordinates against a real MainWindow, and asserts on what the ViewModel did:

Gesture	Must
Click a folder row	open that folder (one load)
Click a subfolder row	open the child, not its parent
Click the expander chevron	collapse the branch, open nothing
Click empty space below the rows	open nothing
Double-click a folder row	open it once
Click a message row	open that message
Press on one row, release over another	open neither
Ctrl+click a second message	extend the selection, open nothing

Gated behind QUICKMAIL_RUN_INPUT_TESTS=1 like the synthesized-keystroke tests, and the CI guard that asserts those actually executed now covers these too — so they cannot quietly stop running.

Safety on a real desktop

Every click first confirms Windows puts the window under test at that screen point and that WPF's input hit test finds the intended element there. A mismatch fails without pressing, so a coordinate error cannot become a stray click on someone's desktop. Press and release are paired in finally blocks: an early version failed mid-drag, left the machine's button held down, and wedged the rest of the run behind it.

Four things the harness had to learn

Written up in the file headers and in CLAUDE.md, where the next person will be standing when they matter:

• The window runs on its own thread with a real Dispatcher.Run() loop. Pumping it from the test thread with DispatcherFrame/PushFrame instead is a nested message loop over a live WebView2 — the deadlock the Modal Dialog Rules describe — and it hung the suite with no output.
• SendInput only queues. Waiting for the dispatcher to go idle races the input it is meant to be waiting for.
• InputHitTest, never VisualTreeHelper.HitTest, to ask what a click would land on: the latter is geometric and returns visuals inside a collapsed subtree, still carrying their last-arranged bounds, so a hidden pane answers for the visible one underneath it.
• The fixture needs an account. With none, start-up opens the Account Manager modally, which disables the window under test — it then receives no input at all while remaining the window WindowFromPoint names and hit-testing correctly in WPF, so every click looks exactly like a click the app ignored.

Two assertions that were wrong about the app

Both now say so where they sit: a WPF ListBox has no native drag-select (so a drag selects one row, and what the test guards is that the release activates nothing), and the app prefetches the details of the whole visible list when a folder opens (so store-load counts cannot tell you a message was opened — the message tests compare MessageDetail identity instead).

Verification

8/8 pass on two consecutive runs; 8/8 skip with a visible reason when the env var is absent. The rest of the suite is unchanged by this — the 7 failures currently on this branch (AccountDialogHintTests, Pop3DialogTests) fail identically with this class excluded and are being looked at separately.

🤖 Generated with Claude Code

[kellylford]

Independent review applied, plus two more that CI found and one that turned out to be mine.

The central guard was not doing its job. It asked whether our window was at the point the test aimed at, and whether a click there would hit the intended element — but that coordinate came from the window's own layout, so it agreed with itself no matter where the pointer actually went. Everything this PR claimed about refusing to click when coordinates are wrong was untrue. It now asks about where the pointer really is.

Also from the review: a constructor throw skipped all cleanup and stranded a topmost window for the rest of the process; Dispose caught only TimeoutException, so a throw from OnClosed skipped the shutdown and replaced the real test failure with a cleanup one; the double-click test waited out a whole folder load between its presses, which past GetDoubleClickTime silently makes it two single clicks (now back-to-back, and it asserts the window was given ClickCount 2); the empty-space test could not tell empty space from a row; Math.Round in the coordinate normalization lands a pixel short; and a handful of smaller ones — DPI context restored in a finally, bounded startup wait, CloseToTray set explicitly, cross-thread read routed properly.

CI found two races this machine is too fast to lose. The guard compared visual instances, which go stale when containers are recycled — the ViewModel finishing a load between resolving a row and moving onto it left the same row on screen as a different object. And the seed lost to the runner's slower startup load: seeding asserted five messages and the list was empty by the time a test looked. The guard now compares the data the hit resolves to, and seeding repeats until it holds.

One was mine and I had called it someone else's. Six AccountDialogHintTests and one Pop3DialogTests failed whenever these ran in the same process. Clicking makes this process foreground; closing the window afterwards leaves the foreground wherever it falls; those tests focus a control on a window shown with ShowActivated = false, which needs the process to hold it. The foreground window is now restored alongside the pointer.

Full suite with the mouse tests on: 3190 passed, 0 failed, twice.