ngwr 11.0.0 → 11.2.0

package/types/ngwr-color-picker-testing.d.ts

@@ -0,0 +1,291 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate } from '@angular/cdk/testing';
+import { WrSegmentedHarness } from 'ngwr/segmented/testing';
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** Which set of numeric fields the picker is showing. */
+type WrColorPickerTab = 'hex' | 'rgb' | 'hsl';
+/** Narrows which `<wr-color-picker>` a harness query matches. */
+interface WrColorPickerHarnessFilters extends BaseHarnessFilters {
+    /**
+     * Match the picker's current colour, as the preview swatch paints it — always
+     * hex, whatever `format` writes into `value`. A string is an exact match, a
+     * RegExp is tested.
+     */
+    readonly color?: string | RegExp;
+    /** Match only pickers showing this tab. */
+    readonly tab?: WrColorPickerTab;
+    /** Match only enabled (`false`) or only disabled (`true`) pickers. */
+    readonly disabled?: boolean;
+}
+/** Narrows which `[wrColorPickerTrigger]` a harness query matches. */
+interface WrColorPickerTriggerHarnessFilters extends BaseHarnessFilters {
+    /** Match the trigger's own text, an exact string or a RegExp. */
+    readonly text?: string | RegExp;
+    /** Match only open (`true`) or only closed (`false`) triggers. */
+    readonly open?: boolean;
+}
+/** The percentage each of the picker's thumbs sits at along its surface. */
+interface WrColorPickerThumbs {
+    /** Saturation across, value down — both 0–100, and `y` is inverted (0 % is full brightness). */
+    readonly sv: {
+        readonly x: number;
+        readonly y: number;
+    };
+    /** Hue along its slider, 0–100 (so 50 is 180°). */
+    readonly hue: number;
+    /** Alpha along its slider, 0–100, or `null` when the picker has no alpha. */
+    readonly alpha: number | null;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/**
+ * Test harness for `<wr-color-picker>` — the inline picker, and the one the
+ * `[wrColorPickerTrigger]` directive mounts in an overlay.
+ *
+ * **What this harness will not do: drag.** The SV canvas and the hue / alpha
+ * sliders are pointer surfaces that read `getBoundingClientRect()` and divide by
+ * its width. A unit test has no layout, so every box is 0×0 and the division is
+ * `NaN` — a `setHue()` built on a synthetic pointer event would report success and
+ * write nothing, or write garbage. The numeric fields reach the same state and are
+ * also the only keyboard path the component has, so they are the whole write API
+ * here. {@link getThumbs} reads where the thumbs ARE, from the percentages the
+ * component writes inline, which is how a spec checks a surface followed a value.
+ *
+ * **And it will not read the preview swatch.** The preview paints the current
+ * colour as a CSS background, and jsdom normalises that to `rgb(…)` — dropping the
+ * alpha channel entirely, so `#ff880080` and `#ff8800ff` come back identical. A
+ * `getColor()` reading it would answer one thing in a unit test and another in a
+ * browser. {@link getHex} is the colour: the field holds the canonical 8-digit
+ * string, alpha included, whatever `format` writes into `value`.
+ *
+ * @example
+ * ```ts
+ * const picker = await loader.getHarness(WrColorPickerHarness);
+ *
+ * await picker.setHex('#3969e2');
+ * expect(await picker.getHex()).toBe('#3969e2ff');
+ *
+ * await picker.setTab('rgb');
+ * expect(await picker.getRgb()).toEqual({ r: 57, g: 105, b: 226 });
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrColorPickerHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrColorPickerHarnessFilters): HarnessPredicate<WrColorPickerHarness>;
+    private readonly hexField;
+    private readonly tabs;
+    /**
+     * The tab switcher, as a {@link WrSegmentedHarness}.
+     *
+     * Handed back rather than re-queried: the switcher IS a `<wr-segmented>`, which
+     * already knows that the roving tab stop is not the selection and how the sliding
+     * thumb reports itself. Re-reading its buttons here would be a second, worse copy.
+     */
+    getTabs(): Promise<WrSegmentedHarness>;
+    /** Which set of numeric fields is showing. */
+    getTab(): Promise<WrColorPickerTab>;
+    /** Show a different set of numeric fields. An already-active tab is left alone. */
+    setTab(tab: WrColorPickerTab): Promise<void>;
+    /**
+     * The canonical hex string, as the HEX field shows it — 8 digits while `alpha` is
+     * on, 6 while it is off.
+     *
+     * This is the picker's colour, and deliberately not the same thing as its `value`:
+     * `format` decides whether `value` is written as hex, `rgb()` or `hsl()`, while the
+     * field always shows hex. A spec that cares about the emitted string should read
+     * the bound signal; one that cares about the COLOUR should read this.
+     *
+     * Throws off the HEX tab, where the field does not exist — see {@link setTab}.
+     */
+    getHex(): Promise<string>;
+    /**
+     * Type a colour into the HEX field.
+     *
+     * Typed rather than assigned, because that is the path the component is built
+     * around: it re-parses on every keystroke and applies the first spelling that
+     * parses, so a partial `#ff8` commits a colour on its way to `#ff8800`. An
+     * unparseable string leaves the committed colour ALONE and lives in the field
+     * until {@link blurHex} snaps it back — assert that rather than expecting a throw.
+     */
+    setHex(value: string): Promise<void>;
+    /**
+     * Blur the HEX field — re-syncing it with the committed colour and emitting
+     * `touch`.
+     *
+     * The re-sync is the visible half: a field left holding text that never parsed
+     * goes back to the canonical hex here, and nowhere else.
+     */
+    blurHex(): Promise<void>;
+    /** Whether the HEX field currently holds focus. */
+    isHexFocused(): Promise<boolean>;
+    /** The three RGB channels as the RGB tab shows them. Throws off that tab. */
+    getRgb(): Promise<{
+        r: number;
+        g: number;
+        b: number;
+    }>;
+    /** Write one RGB channel, 0–255. Out-of-range numbers are clamped by the component. */
+    setRgbChannel(channel: 'r' | 'g' | 'b', value: number): Promise<void>;
+    /**
+     * Hue, saturation and lightness as the HSL tab shows them — degrees and whole
+     * percents, already rounded for display. Throws off that tab.
+     */
+    getHsl(): Promise<{
+        h: number;
+        s: number;
+        l: number;
+    }>;
+    /** Write one HSL channel — `h` in degrees, `s` / `l` in percent. */
+    setHslChannel(channel: 'h' | 's' | 'l', value: number): Promise<void>;
+    /**
+     * Alpha as the whole percent the numeric tabs show, or `null` when the picker was
+     * built without alpha.
+     *
+     * Only the RGB and HSL tabs carry the field — the HEX tab spells alpha into the
+     * hex string instead — so this throws on the HEX tab rather than answering `null`,
+     * which would read as "this picker has no alpha".
+     */
+    getAlphaPercent(): Promise<number | null>;
+    /** Write alpha as a whole percent, 0–100. */
+    setAlphaPercent(value: number): Promise<void>;
+    /**
+     * Whether the picker offers alpha at all.
+     *
+     * From the host modifier, which is the one answer that holds on every tab: the
+     * alpha SLIDER is always rendered when it is on, while the `A%` field only exists
+     * on the two numeric tabs.
+     */
+    hasAlpha(): Promise<boolean>;
+    /**
+     * Whether the picker refuses interaction.
+     *
+     * Read from the modifier the host paints rather than from a field's `disabled`
+     * property, because the fields come and go with the tab while the state does not —
+     * and the drag surfaces, which have no `disabled` of their own, are gated by the
+     * same signal.
+     */
+    isDisabled(): Promise<boolean>;
+    /** The preset colours offered under the fields, as the strings the consumer passed. */
+    getSwatches(): Promise<string[]>;
+    /**
+     * Click a preset.
+     *
+     * Matched on the string the consumer passed, which is what the button publishes as
+     * its accessible name — the rendered background is a CSS colour and would come back
+     * normalised and alpha-stripped. Throws when nothing matches, naming what is offered.
+     */
+    pickSwatch(color: string): Promise<void>;
+    /**
+     * Where the three thumbs sit, in percent along their surfaces.
+     *
+     * The component writes these as inline `left` / `top` percentages, so they are
+     * readable with no layout at all — which makes them the only evidence a spec has
+     * that the surfaces followed a colour set through the fields. A measured position
+     * would be zero for all three.
+     */
+    getThumbs(): Promise<WrColorPickerThumbs>;
+    /** The HEX field's value without the tab check — for filters, which must not throw. */
+    private readHex;
+    private requireHexField;
+    private channelValues;
+    private writeChannel;
+    private requireTab;
+    /** Every numeric input of the current tab, keyed by the label printed under it. */
+    private inputsByLabel;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/**
+ * Test harness for `[wrColorPickerTrigger]` — the element that opens a
+ * `<wr-color-picker>` in an overlay.
+ *
+ * The trigger stays in your fixture; the picker it opens does not. So this harness
+ * is loaded from the fixture loader like any element, and {@link getPicker} reaches
+ * ACROSS into the overlay container for you — scoped by the panel id the trigger
+ * publishes through `aria-controls`, never by `.wr-color-picker-overlay`, which
+ * answers with whichever trigger opened first.
+ *
+ * @example
+ * ```ts
+ * const trigger = await loader.getHarness(WrColorPickerTriggerHarness);
+ * const picker = await trigger.open();
+ *
+ * await picker.setHex('#3969e2');
+ * await trigger.sendEscape();
+ * expect(await trigger.isOpen()).toBe(false);
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrColorPickerTriggerHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrColorPickerTriggerHarnessFilters): HarnessPredicate<WrColorPickerTriggerHarness>;
+    /** The trigger's own text, trimmed. */
+    getText(): Promise<string>;
+    /** Whether the picker is showing, from the trigger's `aria-expanded`. */
+    isOpen(): Promise<boolean>;
+    /**
+     * Whether the trigger refuses to open.
+     *
+     * From `aria-disabled`, which the directive writes for its own `disabled` input.
+     * The host is usually a `<button>`, but the directive does not touch its `disabled`
+     * PROPERTY — a consumer who binds that as well turns the element off at the DOM
+     * level, which is a stronger thing and reads here too.
+     */
+    isDisabled(): Promise<boolean>;
+    /**
+     * The picker this trigger opened, or `null` while it is closed.
+     *
+     * Scoped by the id in `aria-controls`, so two triggers open at once — which
+     * nothing in the component prevents, since only an outside click closes one —
+     * answer with their own panels rather than with whichever came first.
+     */
+    getPicker(): Promise<WrColorPickerHarness | null>;
+    /**
+     * Open the picker and hand it back. An already-open trigger is left alone.
+     *
+     * Throws on a disabled trigger rather than answering `null` three lines later:
+     * `toggle()` returns early while `disabled` is set, so the click lands and nothing
+     * happens at all.
+     */
+    open(): Promise<WrColorPickerHarness>;
+    /** Close the picker. An already-closed trigger is left alone. */
+    close(): Promise<void>;
+    /** Click the trigger once, whichever way that takes it. */
+    toggle(): Promise<void>;
+    /**
+     * Press Escape.
+     *
+     * Sent to the TRIGGER, and it still reaches the picker: the overlay listens through
+     * the CDK's keyboard dispatcher, which keeps one document listener and routes to
+     * the top-most overlay — so this does not depend on where focus happens to be.
+     */
+    sendEscape(): Promise<void>;
+    /** The role the trigger claims to open — `dialog`. */
+    getHasPopup(): Promise<string | null>;
+}
+
+export { WrColorPickerHarness, WrColorPickerTriggerHarness };
+export type { WrColorPickerHarnessFilters, WrColorPickerTab, WrColorPickerThumbs, WrColorPickerTriggerHarnessFilters };

package/types/ngwr-color-picker.d.ts

@@ -236,7 +236,17 @@ declare class WrColorPicker implements FormValueControl<string> {
     protected readonly alphaPercent: _angular_core.Signal<number>;
     protected readonly tabOptions: readonly WrSegmentedOption<Tab>[];
     protected readonly classes: _angular_core.Signal<string>;
-    /** Last string we pushed into `value`; lets the sync effect ignore our own writes. */
+    /**
+     * The one write we just made, held only until the sync effect has seen it.
+     *
+     * It exists so a drag keeps its continuous HSV values instead of being
+     * re-quantised through its own hex round-trip. It used to be set and never
+     * cleared, which turned "ignore this write" into "ignore this STRING,
+     * forever": after the picker emitted `#ff0000` once, an app writing
+     * `#ff0000` back — a reset button, a form patch, an undo — was silently
+     * dropped for the rest of the component's life, and the surface kept
+     * whatever colour the user had dragged to.
+     */
     private lastEmitted;
     constructor();
     protected onPointerDown(event: PointerEvent, surface: Edges): void;
@@ -301,6 +311,8 @@ declare class WrColorPickerTrigger {
     private readonly destroyRef;
     protected readonly isOpen: _angular_core.WritableSignal<boolean>;
     private overlayRef;
+    /** @internal Public so the host binding can read it. */
+    protected readonly panelId: string;
     constructor();
     /** Toggle the picker. Open if closed, close if open. */
     toggle(): void;

package/types/ngwr-context-menu.d.ts

@@ -66,7 +66,21 @@ declare class WrContextMenu {
      */
     protected readonly openMenuId: _angular_core.WritableSignal<string | null>;
     private overlayRef;
-    private closingTimer;
+    /**
+     * Panes waiting out their exit animation, keyed by the timer that disposes
+     * them.
+     *
+     * A SET, because one handle cannot hold two closings. It used to be a single
+     * `closingTimer`, and the second close inside the 220ms window cleared the
+     * first one's timer instead of its own — so the previous pane's `dispose()`
+     * never ran. `onContextMenu` closes and immediately re-opens, so right-clicking
+     * one target faster than the animation orphaned a pane per click: an
+     * `opacity: 0` box with `pointer-events: auto` eating clicks, a never-destroyed
+     * embedded view, a capture-phase document scroll listener still moving it, and
+     * an undetached ref still registered with CDK's keyboard dispatcher — which
+     * swallowed Escape for the whole page.
+     */
+    private readonly closingPanes;
     private leaveTimer;
     private pressTimer;
     private pressX;

package/types/ngwr-date-picker-testing.d.ts

@@ -1,4 +1,6 @@
-import { BaseHarnessFilters, ComponentHarness, HarnessPredicate, TestElement, HarnessLoader } from '@angular/cdk/testing';
+import { WrCalendarDayHarness } from 'ngwr/calendar/testing';
+export { WrCalendarDayHarness as WrDatePickerDayHarness } from 'ngwr/calendar/testing';
+import { BaseHarnessFilters, ComponentHarness, TestElement, HarnessLoader, HarnessPredicate } from '@angular/cdk/testing';
 
 /**
  * @license
@@ -77,68 +79,6 @@ interface WrDatePickerTimeFields {
     readonly seconds?: number;
 }
 
-/**
- * @license
- *
- * Use of this source code is governed by an MIT-style license that can be
- * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
- */
-
-/**
- * Test harness for one day cell of the calendar inside a date-picker popup.
- *
- * Reached through `WrDatePickerHarness.getDay()` / `getDays()` (or the range
- * picker's), which scope it to ONE picker's panel — the cells are in the overlay
- * container, so a bare query would answer with whichever picker opened first.
- *
- * State is read the way a screen reader reads it (`role`, `aria-selected`,
- * `aria-disabled`) with the `.wr-calendar__day--*` modifiers filling in what
- * ARIA has no word for: today, the spill days of the neighbouring months, and
- * the interior of a picked range.
- *
- * @see https://ngwr.dev/guides/testing
- */
-declare class WrDatePickerDayHarness extends ComponentHarness {
-    static hostSelector: string;
-    /** Build a predicate that narrows the query. */
-    static with(options?: WrDatePickerDayHarnessFilters): HarnessPredicate<WrDatePickerDayHarness>;
-    /** The day number as rendered. */
-    getText(): Promise<string>;
-    /** The day number as a number, for mapping a list of cells to dates. */
-    getDayOfMonth(): Promise<number>;
-    /** `'gridcell'` — the cell is a button, and the grid semantics are what a spec should assert. */
-    getRole(): Promise<string | null>;
-    /** Whether this day is (one end of) the current selection. */
-    isSelected(): Promise<boolean>;
-    /**
-     * Whether the day refuses selection — `min` / `max` or `dateFilter` ruled it
-     * out, or the whole calendar is disabled.
-     */
-    isDisabled(): Promise<boolean>;
-    /** Whether the cell is today's date. */
-    isToday(): Promise<boolean>;
-    /**
-     * Whether the cell belongs to a neighbouring month. The grid is always 6x7, so
-     * every month is padded with days that are selectable but not "in" the month —
-     * which is why {@link WrDatePickerHarness.getDay} skips them.
-     */
-    isOutOfMonth(): Promise<boolean>;
-    /** Whether the day lies strictly between the two ends of a picked range. */
-    isInRange(): Promise<boolean>;
-    /**
-     * Whether this is the roving cell — the grid's single tab stop, and where the
-     * arrow keys move from.
-     *
-     * At most ONE cell answers `true`, and it is not always one: the calendar's
-     * roving date does not follow `next()` / `previous()`, so a grid navigated away
-     * from that month has no active cell (and, deliberately or not, no tab stop)
-     * until a cell is clicked or the arrows move it.
-     */
-    isActive(): Promise<boolean>;
-    /** Click the cell. A disabled cell swallows the click — assert, do not assume. */
-    click(): Promise<void>;
-}
-
 /**
  * @license
  *
@@ -277,12 +217,12 @@ declare abstract class WrDatePickerHarnessBase extends ComponentHarness {
      * them, since the grid is always six weeks and pads into the neighbouring
      * months.
      */
-    getDays(filters?: WrDatePickerDayHarnessFilters): Promise<WrDatePickerDayHarness[]>;
+    getDays(filters?: WrDatePickerDayHarnessFilters): Promise<WrCalendarDayHarness[]>;
     /**
      * One day of the month on show. The padding days of the neighbouring months are
      * skipped, so `getDay(1)` is the 1st of THIS month and never the 1st of the next.
      */
-    getDay(dayOfMonth: number): Promise<WrDatePickerDayHarness>;
+    getDay(dayOfMonth: number): Promise<WrCalendarDayHarness>;
     /** Click a day of the month on show. */
     selectDay(dayOfMonth: number): Promise<void>;
     /** The trigger button. Both components render it with the same class. */
@@ -514,5 +454,5 @@ declare class WrDateRangePickerHarness extends WrDatePickerHarnessBase {
     private timePanel;
 }
 
-export { WrDatePickerDayHarness, WrDatePickerHarness, WrDateRangePickerHarness };
+export { WrDatePickerHarness, WrDateRangePickerHarness };
 export type { WrDatePickerDayHarnessFilters, WrDatePickerHarnessFilters, WrDatePickerTimeFields, WrDateRangePickerHarnessFilters };

package/types/ngwr-decrypt-text-testing.d.ts

@@ -0,0 +1,222 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate } from '@angular/cdk/testing';
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** Narrows which `<wr-decrypt-text>` a harness query matches. */
+interface WrDecryptTextHarnessFilters extends BaseHarnessFilters {
+    /**
+     * Match the string the component ANNOUNCES — the readable copy, never the scramble.
+     * A string is an exact match, a RegExp is tested.
+     *
+     * This is the only stable thing to address one of these by: the visible layer is a
+     * fresh random draw on every tick, so a filter written against it would match a
+     * different element each time it ran, or none at all.
+     */
+    readonly text?: string | RegExp;
+    /**
+     * Match only settled (`true`) or only scrambled (`false`) instances — the way to pick
+     * out the one that has not been revealed yet on a page holding several.
+     *
+     * Read from the encrypted characters rather than from the glyphs, so it needs no
+     * `Math.random` stub. An instance that rendered no characters at all matches NEITHER
+     * value: "nothing is encrypted" is true of nothing, and a query is the last place that
+     * vacuity should quietly hand back a match.
+     */
+    readonly revealed?: boolean;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/**
+ * Test harness for `<wr-decrypt-text>`.
+ *
+ * **Two layers, two questions, and they are meant to disagree.** The component renders
+ * the real string once in a visually-hidden span and the scramble in a parallel
+ * `aria-hidden` layer, so {@link getAccessibleText} is what a screen reader hears and
+ * {@link getRenderedText} is what a sighted reader sees. Mid-reveal the second is
+ * literal gibberish while the first must be untouched — that is the contract, and it is
+ * the half nobody looks at. A spec asserting only the visible glyphs would pass on a
+ * component that announced `XQ#PZ`.
+ *
+ * **Prefer the class over the glyphs.** {@link getRevealedIndices},
+ * {@link getEncryptedCount} and {@link isFullyRevealed} read
+ * `.wr-decrypt-text__char--encrypted`, which is deterministic with no stubbing at all —
+ * they are what tell `revealDirection` `'start'` from `'end'` from `'center'`, one index
+ * per tick. {@link getRenderedText} reads the glyphs themselves, which are a fresh
+ * `Math.random()` draw per tick, so stub it (`vi.spyOn(Math, 'random')
+ * .mockReturnValue(0)`) before asserting a string.
+ *
+ * **The clock is the spec's, not the harness's.** The reveal is a `setInterval` this
+ * class does not own, so there is no `advance(ms)` and no `waitUntilRevealed()`: one
+ * would flake on a loaded machine and the other would silently require fake timers to
+ * have been installed. Fake `setInterval` / `clearInterval` and nothing else — faking
+ * the microtask queue freezes the stabilization every `await harness.*()` runs through —
+ * then advance the clock yourself between reads.
+ *
+ * **There is no keyboard path, and this harness does not pretend there is one.**
+ * {@link hover}, {@link mouseAway} and {@link click} are the component's only triggers;
+ * with `animateOn="click"` the host takes a click handler while carrying no role, no
+ * `tabindex` and no keydown handler, so a `focus()` / `sendKeys(Enter)` affordance here
+ * would make a spec pass while a keyboard or switch user could not reveal the text at
+ * all. There is no `enterViewport()` either: `'view'` and `'inViewHover'` hang off an
+ * `IntersectionObserver` jsdom does not implement, so the spec stubs the global and
+ * fires it.
+ *
+ * **Also deliberately absent:** `isAnimating()` — the component has such a signal and it
+ * never reaches the DOM, and deriving it from "something is encrypted" would be wrong in
+ * exactly the interesting case, since `animateOn="click"` rests fully encrypted and
+ * perfectly still. `getSpeed()` / `getMaxIterations()` / `getRevealDirection()` /
+ * `getClickMode()` / `getAnimateOn()` — inputs that are never reflected anywhere, so
+ * reporting them would mean reading the component instance rather than the rendered
+ * control; they are observable as behaviour, which is what the methods above measure.
+ * `getScrambleAlphabet()` — the pool is internal and each frame shows one random draw
+ * from it, so any reconstruction is a guess that gets worse the shorter the string.
+ * `getCharColors()` / `isDimmed()` — the `--encrypted` rule is deliberately EMPTY, a
+ * styling hook for consumers, so there is nothing painted to read in any environment.
+ *
+ * @example
+ * ```ts
+ * const secret = await loader.getHarness(WrDecryptTextHarness.with({ text: 'Hello' }));
+ *
+ * await secret.hover();
+ * vi.advanceTimersByTime(50);
+ *
+ * expect(await secret.getRevealedIndices()).toEqual([0]);   // sequential, from the start
+ * expect(await secret.getAccessibleText()).toBe('Hello');   // untouched throughout
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrDecryptTextHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrDecryptTextHarnessFilters): HarnessPredicate<WrDecryptTextHarness>;
+    private readonly chars;
+    private readonly encrypted;
+    /**
+     * The real string, as the one readable copy holds it.
+     *
+     * The single highest-value assertion here: it must stay equal to the `text` input on
+     * every frame, while the visible layer is unreadable by design. Lose this span and the
+     * component announces nothing at all — every drawn character sits under `aria-hidden`,
+     * so no other part of the DOM would change.
+     *
+     * Untrimmed, so that it can be compared against {@link getRenderedText} without one
+     * side of the comparison quietly forgiving a lost leading space.
+     */
+    getAccessibleText(): Promise<string>;
+    /**
+     * What is on screen this frame — scramble glyphs and all, in document order.
+     *
+     * Plain before anything triggers it, gibberish mid-reveal, and the real string once it
+     * settles; comparing it against {@link getAccessibleText} is how a spec says which of
+     * those it is looking at. `useOriginalCharsOnly` is visible only here — every glyph
+     * has to be one the text really contains.
+     *
+     * Nondeterministic unless the spec stubs `Math.random`, because each unrevealed
+     * position is an independent draw from the pool. When the assertion does not actually
+     * need the glyphs, {@link getRevealedIndices} answers the same progress question off
+     * the class and needs no stub.
+     */
+    getRenderedText(): Promise<string>;
+    /**
+     * How many characters the animation walks.
+     *
+     * CODE POINTS, not UTF-16 units: `'a🚀b'` is 3 here, and the indices
+     * {@link getRevealedIndices} returns line up with `[...text]` rather than with plain
+     * `text[i]`. That distinction is not pedantry — counting units gave a sequential
+     * reveal extra ticks with no character to spend them on, and made "everything is
+     * revealed" disagree with what was on screen.
+     */
+    getCharCount(): Promise<number>;
+    /**
+     * The positions that have settled on their real character, ascending.
+     *
+     * The payload method, and the deterministic one: it reads the `--encrypted` modifier
+     * rather than the glyphs, so no `Math.random` stub is involved. It is the only thing
+     * that separates `revealDirection` `'start'` (`[0]`, `[0, 1]`, …) from `'end'`
+     * (`[4]`, `[3, 4]`, …) from `'center'` (`[2]`, `[1, 2]`, …), and one index per tick is
+     * what makes a sequential reveal sequential.
+     *
+     * Ascending by position, NOT in the order the reveal visited them — the DOM records
+     * which characters have landed, never the path taken to them. Assert the set after
+     * each tick to pin an order.
+     */
+    getRevealedIndices(): Promise<number[]>;
+    /**
+     * How many characters are still scrambled.
+     *
+     * The coarse progress read, and the cheapest way to say "scrambled on hover", "plain on
+     * leave", or "a reader who asked for less motion never saw a scramble at all". Class-
+     * based like {@link getRevealedIndices}, so it too is random-proof.
+     */
+    getEncryptedCount(): Promise<number>;
+    /**
+     * Whether every character has settled.
+     *
+     * Deliberately does NOT also compare {@link getRenderedText} against
+     * {@link getAccessibleText}: folding two conditions into one boolean hides which of
+     * them broke, and a spec that wants both should write both lines.
+     *
+     * Throws when nothing was rendered. "No character is encrypted" is true of no
+     * characters, which is the same answer a component that stopped rendering its text
+     * would give — and this is the method most likely to be the only assertion in a test.
+     */
+    isFullyRevealed(): Promise<boolean>;
+    /**
+     * Whether the scramble layer is out of the accessibility tree.
+     *
+     * The contract that keeps a screen reader from spelling out `XQ#PZ` beside the real
+     * string it already read. Worth a method rather than an assumption because the wrapper
+     * holding the characters carries NO class — it can only be addressed as the readable
+     * span's next sibling, which any template reshuffle breaks.
+     *
+     * Throws when that structural selector finds nothing, rather than returning `false`: a
+     * missing wrapper and an unhidden one are different failures, and the answer to
+     * "is the scramble hidden" when there is no scramble layer at all is not `false`.
+     */
+    isAnimatedLayerHidden(): Promise<boolean>;
+    /**
+     * Point at it — the trigger for `animateOn` `'hover'` and `'inViewHover'`.
+     *
+     * Drives the component the way a user does, and works in a test because the trigger is
+     * an event rather than a gesture: `TestElement.hover()` dispatches `pointerenter`,
+     * `mouseover` and `mouseenter`, and the component listens for the last of those. A
+     * hand-rolled pointer-only dispatch would not reach it.
+     *
+     * Does nothing in the other two modes, exactly as a real pointer does nothing there.
+     */
+    hover(): Promise<void>;
+    /**
+     * Move the pointer off — the other half of hover mode.
+     *
+     * Pins the promise that leaving mid-scramble restores the real text IMMEDIATELY rather
+     * than letting the reveal play out: the reader took the effect away, so the string has
+     * to come back at once.
+     */
+    mouseAway(): Promise<void>;
+    /**
+     * Click the host — the `animateOn="click"` trigger, and the only way to tell
+     * `clickMode` `'once'` from `'toggle'`.
+     *
+     * There is no keyboard equivalent, and that is a statement about the component rather
+     * than about this harness: in click mode the host carries a click handler with no role,
+     * no `tabindex` and no keydown handler, so a keyboard or switch user cannot reveal the
+     * text at all. A `sendKeys(Enter)` here would invent an affordance that does not exist
+     * and let a spec pass over the top of it.
+     */
+    click(): Promise<void>;
+}
+
+export { WrDecryptTextHarness };
+export type { WrDecryptTextHarnessFilters };