test(web): aim panel tab clicks at the title, not the tab - #572
Merged
Conversation
A service tile's tab is as wide as whatever the panel contributes into its header, so an element-centre click on the tab lands inside a contributed control — for artifacts, its search input — and focuses nothing. Focus the tab title instead, which always means "focus this tile". The rail-drag drop sequence now waits for dockview's own drop-target overlay instead of two fixed sleeps. dockview resolves the target asynchronously and only after a dragover it has processed, so the fixed budget expired under load and the drop was silently ignored; a drop with no resolved target now fails by name rather than as a missing tab.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three tests in
test_panels_browser.pyfail or flake onmain, and the browser lane is path-filtered so nothing under those paths had changed to surface them.Two of them click a service tile's dock tab as a whole. That was fine when a tab was just a title and a close button, but a panel now contributes controls into its own tile header — artifacts renders a search box and filter chips — which widens the tab to roughly 417px. Playwright clicks an element's centre, so the click lands in the search input: no tile focus, no focus POST, and the assertions fail on the downstream symptom rather than the cause. One of the two only failed intermittently because it raced the contributions rendering; a narrow tab still hit the title. A third site was passing on the same luck.
The drag test is unrelated. Its synthetic HTML5 drag gave dockview two fixed 100ms sleeps to process a
dragoverand resolve a drop target. dockview resolves that asynchronously and needs more than one processeddragover, so under the load of a full-file run the budget expired, the drop was silently ignored, and the failure surfaced as a missing tab.Focusing the tab title is the durable target: it is the region that means "focus this tile" regardless of what a panel contributes beside it. The drag now polls for dockview's own
.dv-drop-target-selection.dv-drop-target-bottomoverlay, which both waits on the real signal and doubles as an assertion that the geometry resolved to an edge split — and throws by name if it never does.Test-only; no product behaviour changes. Verified against
6c2d8473's parent that the focus-echo commit did not cause any of this. Full file 36/36 twice, and CI's exact browser-lane command 114 passed locally.