feat(admin-bar): shortcuts popover, dock-style tooltips, reorder#223
Merged
epeicher merged 2 commits intoMay 15, 2026
Merged
Conversation
…style tooltips Drop the redundant text labels from Fullscreen, Report a bug, and Arrange. The admin bar now reads as a row of icons matching the dock. Fix the Report a bug icon. The inline CSS forced `\f465` (dashicons-email, an envelope) under a class declared as `dashicons-buddicons-replies` — the admin bar rendered a different glyph than the dock tile. Use the real codepoint `\f451` so both surfaces show the same speech-bubble icon. Add a "Keyboard shortcuts" admin-bar entry. The icon is a custom inline-SVG keyboard glyph rendered via a CSS `mask` with `background-color: currentColor` (dashicons has no keyboard glyph). Clicking toggles a floating popover anchored under the button, styled to match the Arrange submenu (white bg, soft shadow, rounded corners). Content is translated server-side and shipped via `desktopModeAdminBar.shortcuts`. The popover covers the desktop / overview arrow-key table (left / right / up / down / Enter, with distinct behaviour outside overview, inside overview, and in Show Desktop) plus the cross-mode shortcuts (backtick, Shift+backtick, Cmd/Ctrl+K, Esc). Add dock-style tooltips on every icon-only admin-bar button. admin-bar.js rewrites the native `title` to `data-desktop-tooltip` and mirrors it to `aria-label` so the OS-delayed native tooltip never competes with a CSS `::after` pseudo-element rendering the dark pill underneath. The tooltip on the keyboard-shortcuts anchor is suppressed while its popover is open so the two never stack. Reorder the secondary admin-bar entries by purpose. Left to right: Switch to Classic Admin (mode toggle, escape hatch), Fullscreen and Arrange (shell-state cluster), Ask AI (primary action, central), Keyboard shortcuts and Report a bug (help/meta cluster, anchored next to the user identity menu — matches the convention most SaaS products use for Help / "?" near the user-menu corner).
…gate arrows Every `<wpd-*>` component attaches an open shadow root. When focus lands on an inner `<input>` or `<textarea>`, `document.activeElement` returns the host element, not the leaf — `instanceof HTMLInputElement` returned `false` and the gate classified the host as non-text. Bare backtick and the new arrow-key desktop shortcuts then fired while the user was typing into shell-side inputs (OS Settings AI tab API-key input, Plugins window search box, Open URL dialog, etc.). Walk through each open shadow root's own `activeElement` before the existing INPUT / TEXTAREA / contenteditable checks. Closed shadow roots stop the walk on their own (their `activeElement` is `null` from outside). The iframe / Gutenberg case is unaffected — focus lands on the `<iframe>` element itself, caught by the existing `HTMLIFrameElement` branch. Tighten the `isContentEditable` access for the new `Element | null` typing (`el instanceof HTMLElement && ...`). Adds three vitest cases: single-level shadow input (positive), two-level nested shadow textarea (positive, walks the chain), button inside shadow (negative — still respects element type).
✅ 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
Admin bar now reads as a row of icons matching the dock, with a keyboard-shortcuts popover, dock-style tooltips on every icon, and a purpose-grouped reorder. Bundled fix: the text-entry gate now walks shadow roots, so typing into
<wpd-*>inputs no longer triggers the new arrow-key desktop shortcuts.What changed in the admin bar
Icon-only buttons. Fullscreen, Report a bug, and Arrange drop their text labels. Hover surfaces the new dock-style tooltip instead.
Bug-report glyph fix. The inline CSS was forcing
\f465(dashicons-email, an envelope) under adashicons-buddicons-repliesclass. The admin bar therefore showed a different icon than the dock tile. Use the real\f451so the two surfaces match.Keyboard shortcuts popover. New admin-bar entry with a custom inline-SVG keyboard icon (dashicons has no keyboard glyph). Clicking toggles a floating popover anchored under the button, styled like the Arrange submenu: white background, soft shadow, rounded corners. Closes on click-outside or
Esc. Content is translated server-side viadesktopModeAdminBar.shortcutsand covers:←/→/↑/↓/Enter) with the three columns from the spec: Outside overview, Inside overview, In Show Desktop.⌘/Ctrl+K,Esc.Dock-style tooltips. admin-bar.js rewrites each icon button's native
titletodata-desktop-tooltipand mirrors it toaria-label. A CSS::afterpseudo-element renders the dark pill below the button, identical visual to the dock. The tooltip on the keyboard-shortcuts anchor is suppressed while its popover is open so the two never stack.Reorder by purpose. Left to right in the secondary admin bar:
This matches the convention most SaaS products use for Help / "?" near the user-menu corner.
Bundled fix:
isTextEntryFocusand shadow DOMEvery
<wpd-*>component attaches an open shadow root. When focus lands on an inner<input>or<textarea>,document.activeElementreturns the host element, not the leaf, soinstanceof HTMLInputElementreturnedfalseand the gate classified the host as non-text. Bare backtick (window switcher) and the new arrow-key desktop shortcuts (PR #221) therefore fired while the user was typing into shell-side inputs: OS Settings AI tab API-key input, Plugins window search box, the Open URL dialog, posts-window filters, etc.isTextEntryFocusnow walks through each open shadow root's ownactiveElementbefore the existing INPUT / TEXTAREA / contenteditable checks. Closed shadow roots stop the walk on their own (theiractiveElementisnullfrom outside). The iframe / Gutenberg case is unaffected — focus is the<iframe>element itself, caught by the existingHTMLIFrameElementbranch.Test plan
tests/vitest/switcher.test.ts: single-level shadow input (positive), two-level nested shadow textarea (positive, walks the chain), button-in-shadow negative.