@celestia-island/hikari 0.55.174 → 0.55.175

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celestia-island/hikari",
-  "version": "0.55.174",
+  "version": "0.55.175",
   "private": false,
   "type": "module",
   "description": "Hikari Vue 3 component library — production-grade UI components based on shittim-chest design system",

package/src/runtime/tooltipBridge.test.ts

@@ -15,6 +15,10 @@ import { usePopupManager } from "./usePopupManager";
  * - escape hatches: empty titles, [data-hk-tooltip-native], elements
  *   inside an HkTooltip wrapper — never engage
  * - pointerdown hides but stays engaged; scroll/resize and Esc disengage
+ * - the popup mounts inside #hk-overlay-root (same home as the component
+ *   tooltip's teleported popup) — at body level its in-root ordinal z
+ *   would land under the root's document-space elevation and every
+ *   overlay-hosted surface (the filter panel popover) clipped it
  * - idempotent install per document; uninstall tears everything down
  */
 
@@ -199,6 +203,13 @@ describe("installHkTooltipBridge", () => {
     expect(el.getAttribute("title")).toBe("Scrolled");
   });
 
+  it("mounts the popup inside the overlay root", () => {
+    install();
+    const root = document.querySelector("#hk-overlay-root");
+    expect(root).not.toBeNull();
+    expect(bridgePopup()?.parentElement).toBe(root);
+  });
+
   it("is idempotent per document and uninstallable", () => {
     vi.useFakeTimers();
     install();

package/src/runtime/tooltipBridge.ts

@@ -25,9 +25,15 @@
 //   - empty / whitespace-only titles never engage
 //
 // The bridge holds one popup-manager handle (kind "tooltip"), so its
-// popups share the tooltip z band with component tooltips. Installing
-// twice on the same document is idempotent: the second install returns
-// the first install's uninstall.
+// popups share the tooltip z band with component tooltips — inside the
+// overlay root, which is where the popup MOUNTS (same home as the
+// HkTooltip component's teleported popup: the in-root ordinal z is
+// meaningless at body level once #hk-overlay-root carries its own
+// document-space elevation). Installing twice on the same document is
+// idempotent: the second install returns the first install's uninstall.
+// Side effect: ensures #hk-overlay-root exists before the install appends
+// the popup (the component tooltip's Teleport target is the same node).
+import { ensureOverlayRoot } from "../overlay/overlayRoot";
 import { applyTooltipPosition, type TooltipPlacement } from "./tooltipPosition";
 import { usePopupManager, type PopupHandle } from "./usePopupManager";
 import { reportHkRuntime, type HkRuntimeHandle } from "./registry";
@@ -206,7 +212,19 @@ export function installHkTooltipBridge(options: HkTooltipBridgeOptions = {}): ()
   const content = document.createElement("div");
   content.className = "hk-tooltip-content";
   popup.appendChild(content);
-  document.body.appendChild(popup);
+  // Mount into the overlay root, NOT <body> (2026-10-16 defect report):
+  // the manager's z here is the IN-ROOT ordinal band (tooltip 300, above
+  // anchored popups 200) — it only competes inside the root's
+  // `isolation: isolate` fence. At body level the same number is a
+  // near-bottom document z, far under `#hk-overlay-root`'s own elevation
+  // (--hk-z-overlay-root, 90000), so every tooltip the bridge showed over
+  // an overlay-hosted surface — the filter panel's operator `title=`s
+  // over its popover — painted UNDER the panel and was clipped by it.
+  // The component tooltips teleport into the root for exactly this
+  // reason; the bridge shares their popup classes AND must share their
+  // home. `pointer-events` stays none on both the root and the popup, so
+  // the hosting subtree changes nothing about hit-testing.
+  ensureOverlayRoot().appendChild(popup);
 
   const state: BridgeState = {
     root: document,

package/src/runtime/tooltipPosition.ts

@@ -16,12 +16,19 @@ export const TOOLTIP_GAP_PX = 8;
  * Build the inline style that pins a `position: fixed` popup to one side
  * of a trigger rect.
  *
- * The popup teleports to <body> — inside any root CSS zoom subtree —
- * while `rect` is already in the root visual space (standardized zoom
+ * The popup floats OUTSIDE the page's zoomed subtrees — the HkTooltip
+ * component teleports it into #hk-overlay-root and the bridge appends
+ * it there too, both mounted under unzoomed <body>, outside every
+ * zoomed subtree — while `rect`
+ * is already in the root visual space (standardized zoom
  * reports ancestor zoom applied). The browser scales the tooltip's local
  * px back up at paint, so the visual rect values must be written divided
  * by the cumulative zoom or the tooltip drifts zoom× off its trigger
- * (chest's root-level manual DPI scale).
+ * (chest's root-level manual DPI scale). This contract quietly assumes
+ * the overlay root itself never carries a CSS zoom: the anchor math here
+ * divides by ancestorZoom(document.body) only, while the clamp pass
+ * below divides by ancestorZoom(popup) — the two agree exactly because
+ * the root sits unzoomed between them.
  *
  * `width: max-content` is the position-independence contract (same rule
  * as .hk-popover-panel): a fixed element otherwise shrink-to-fits against