fix(dock): light indicators for native-window-target dock icons (#235)#245
Merged
Merged
Conversation
…cons (#235) When a desktop icon registered with `'window' => '<native-id>'` (no `url`) is promoted to the dock via `itemVisibility`, the synthesized tile carried `url: ''`. The dock's indicator + hover-peek both keyed off `deriveWindowId(item.url)`, which on an empty url produces a baseId that never matches the open native window — so the active / focused dot stayed dark and the peek card never appeared, both on fresh opens and after session restore. Fix: carry the icon's `window` field through synthesis as a new optional `windowId` on `DockItem`, and resolve baseId via a shared `resolveItemBaseId()` helper that prefers `windowId` before falling back to the URL-derivation chain (remap → deriveWindowId). The indicator path and the hover-peek now stay in lockstep through one method.
Contributor
✅ WordPress Plugin Check Report
📊 ReportAll checks passed! No errors or warnings found. 🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check |
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
1 participant
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.
Summary
Closes #235.
When a desktop icon registered with
'window' => '<native-id>'(nourl) is promoted to the dock viaitemVisibility('dock'or'both'),applyDockPlacementsynthesized aDockItemwithurl: ''. The dock's active/focused indicator and hover-peek both keyed offderiveWindowId(item.url)— on an empty URL that produces a baseId that never matches the open native window's id (e.g.desktop-mode-my-wordpress). Result: the dot stayed dark and the peek card never appeared, both for fresh opens and after session restore.Fix
src/dock.ts— added optionalwindowId?: stringonDockItem; introducedresolveItemBaseId()which preferswindowId, thenresolveNativeUrlRemap(item.url), thenderiveWindowId(item.url). The active-state pass and the hover-peek baseId now both route through it, so they stay in lockstep.src/settings/item-placement.ts— synthesized dock tiles carrywindowId: icon.window || undefinedso the dock has a direct key into the window manager for native-window targets.Test plan
npm run lint— cleannpx tsc --noEmit— cleannpm run test:js— 1441 passing (+2 new cases initem-visibility-flow.test.ts: synth-from-window-icon carrieswindowId; synth-from-url-icon leaves it undefined)npm run build— clean