ngwr 10.2.1 → 11.1.0

package/types/ngwr-config.d.ts

@@ -0,0 +1,176 @@
+import { EnvironmentProviders, Signal, InjectionToken } from '@angular/core';
+
+/**
+ * @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
+ */
+/**
+ * The size scale every control shares.
+ *
+ * Declared here rather than imported from a component, and that is deliberate:
+ * `ngwr/config` must not depend on the entry points that depend on IT, or
+ * ng-packagr refuses the build. Nothing drifts silently as a result — a component
+ * reads its default through {@link useConfigValue}, whose generic is the
+ * component's OWN size type, so narrowing `WrButtonSize` would stop that call
+ * compiling. The type checker is the parity guard.
+ */
+type WrControlSize = 'sm' | 'md' | 'lg';
+/** Defaults every control-shaped component understands. */
+interface WrControlDefaults {
+    /** `sm` / `md` / `lg`. */
+    readonly size?: WrControlSize;
+    /** Pill-shaped rather than the standard radius. */
+    readonly rounded?: boolean;
+}
+/**
+ * App-wide component defaults.
+ *
+ * Every field is a DEFAULT, never an override: a value bound on the element
+ * always wins, so a config is what a component falls back to rather than
+ * something a template has to fight. That ordering is the whole design — the
+ * lesson from NG-ZORRO's `NzConfigService`, where a global set could not be
+ * turned off locally and consumers ended up re-stating every input to escape it.
+ *
+ * Empty by default. A component with no config behaves exactly as it does today.
+ *
+ * @example
+ * ```ts
+ * provideWrConfig({
+ *   button: { size: 'sm' },
+ *   input: { size: 'sm' },
+ *   select: { size: 'sm', rounded: true },
+ * })
+ * ```
+ *
+ * Two keys are deliberately absent, and it is worth knowing why before adding
+ * them back.
+ *
+ * **No `color`.** The library's own chrome binds `[color]="isCurrent ? 'primary' :
+ * null"` — `pagination`, the `event-calendar` view switcher — where `null` means
+ * "neutral". {@link useConfigValue} reads `null` as "the template said nothing", so
+ * a configured intent would repaint every one of those buttons. There is no value
+ * in `WrColor` that means "no intent", so a colour default cannot be made safe
+ * without inventing a sentinel, and a sentinel is a worse API than no key.
+ *
+ * **No `button.shape`.** A button's corner treatment is three-valued
+ * (`rounded` / `pill` / `squircle`) and its type lives in `ngwr/button`, which
+ * imports THIS entry point — naming it here would be a circular dependency
+ * ng-packagr refuses. A boolean `rounded` was tried and rejected: it cannot express
+ * `squircle`, and its polarity inverts the component's own vocabulary, where
+ * `rounded` is the value a `false` would produce.
+ */
+interface WrConfig {
+    readonly button?: Pick<WrControlDefaults, 'size'>;
+    readonly checkbox?: Pick<WrControlDefaults, 'size'>;
+    readonly input?: WrControlDefaults;
+    readonly inputNumber?: WrControlDefaults;
+    readonly inputOtp?: Pick<WrControlDefaults, 'size'>;
+    /**
+     * Defaults for `<wr-markdown>`.
+     *
+     * Both keys are app-wide policy rather than per-instance taste, which is the
+     * test a config key has to pass: whether links in rendered markdown open in a
+     * new tab, and whether code blocks carry a copy button, are decisions an app
+     * makes once. `linkTarget` is spelled as a literal union rather than imported
+     * from `ngwr/markdown` for the reason `button.shape` is absent — that entry
+     * point imports this one, and ng-packagr refuses the cycle.
+     */
+    readonly markdown?: {
+        readonly linkTarget?: '_blank' | '_self';
+        readonly copyable?: boolean;
+    };
+    readonly radio?: Pick<WrControlDefaults, 'size'>;
+    readonly select?: WrControlDefaults;
+    readonly switch?: Pick<WrControlDefaults, 'size'>;
+    readonly textarea?: Pick<WrControlDefaults, 'size'>;
+}
+
+/**
+ * @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
+ */
+
+/**
+ * Set app-wide component defaults.
+ *
+ * Nothing is activated by this and no service is constructed — unlike
+ * `provideWrDensity()`, which has to instantiate its service to write an
+ * attribute onto `<html>`. A config is read on demand by whichever component
+ * wants a default, so providing it costs one token.
+ *
+ * @example
+ * ```ts
+ * bootstrapApplication(App, {
+ *   providers: [provideWrConfig({ button: { size: 'sm' }, select: { rounded: true } })],
+ * });
+ * ```
+ *
+ * Scoped use works the same way: put it in a route's `providers` and only that
+ * branch of the tree sees it, because the components resolve the token through
+ * their own injector.
+ *
+ * @see https://ngwr.dev/start/configuration
+ */
+declare function provideWrConfig(config: WrConfig): EnvironmentProviders;
+
+/**
+ * @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
+ */
+
+/**
+ * Resolve an input against the app's {@link WrConfig}, then a built-in fallback.
+ *
+ * The same shape as `useI18nText` from `ngwr/i18n`, and for the same reason: a
+ * component's default has three possible sources and exactly one precedence
+ * order, so it is worth writing once.
+ *
+ * 1. What the template bound, if it bound anything.
+ * 2. What `provideWrConfig()` set for this component.
+ * 3. The component's own fallback.
+ *
+ * A bound value always wins. That is what keeps a global config from becoming
+ * something templates have to escape — the mistake NG-ZORRO's `NzConfigService`
+ * is remembered for.
+ *
+ * Call it from a field initializer (it injects), and give the input `null` as its
+ * own default so "not set" is expressible:
+ *
+ * ```ts
+ * readonly size = input<WrButtonSize | null>(null);
+ * protected readonly resolvedSize = useConfigValue(this.size, c => c.button?.size, 'md');
+ * ```
+ *
+ * The generic is the COMPONENT's type, not the config's, so a component whose
+ * size scale is narrower than {@link WrControlSize} stops compiling here rather
+ * than accepting a value it cannot render — the type checker doing the work a
+ * parity script would otherwise have to.
+ */
+declare function useConfigValue<T>(binding: Signal<T | null | undefined>, pick: (config: WrConfig) => T | undefined, fallback: T): Signal<T>;
+
+/**
+ * @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
+ */
+
+/**
+ * App-wide component defaults, or `{}` when the app never called
+ * `provideWrConfig()`.
+ *
+ * A factory default rather than an optional inject at every call site: a
+ * component asking for its own default should not have to care whether anyone
+ * configured anything, and `{}` reads the same as absent through
+ * {@link useConfigValue}.
+ */
+declare const WR_CONFIG: InjectionToken<WrConfig>;
+
+export { WR_CONFIG, provideWrConfig, useConfigValue };
+export type { WrConfig, WrControlDefaults, WrControlSize };

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

@@ -0,0 +1,401 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate, ContentContainerComponentHarness, HarnessLoader } 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 `[wrContextMenu]` target a harness query matches. */
+interface WrContextMenuHarnessFilters extends BaseHarnessFilters {
+    /**
+     * Match the target's visible text — the content of whatever element the
+     * consumer put `[wrContextMenu]` on, which is usually the thing being
+     * right-clicked rather than a label. A string is an exact match, a RegExp is
+     * tested.
+     */
+    readonly text?: string | RegExp;
+    /** Match only targets whose menu is showing (`true`) or shut (`false`). */
+    readonly open?: boolean;
+}
+/** Narrows which item inside a context menu a harness query matches. */
+interface WrContextMenuItemHarnessFilters extends BaseHarnessFilters {
+    /** Match the item's label — a string is an exact match, a RegExp is tested. */
+    readonly text?: string | RegExp;
+    /** Match only enabled (`false`) or only disabled (`true`) items. */
+    readonly disabled?: boolean;
+    /** Match only items that own a nested submenu (`true`), or only leaves (`false`). */
+    readonly hasSubmenu?: 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 one `<wr-context-menu-item>` inside a context menu.
+ *
+ * The selector is the CLASS rather than the element, matching
+ * `.wr-dropdown-item`: it is public API, and it is on the host whichever way the
+ * item was written. A `<wr-context-menu-divider>` is deliberately not one of
+ * these — it announces `role="separator"` rather than `menuitem`, so it is not
+ * something a user can land on and not a member of the item list
+ * (`WrContextMenuHarness.getDividerCount()` counts those).
+ *
+ * An item that owns a `[submenu]` is also the way INTO it: the submenu is a
+ * second overlay pane, a sibling of the root menu rather than a child of the
+ * item, and it is reached through the id the item publishes as `aria-controls`
+ * while it is open. `getSubmenuItems()` answers with these same harnesses, so a
+ * chain of any depth is walked by repeating the call.
+ *
+ * @example
+ * ```ts
+ * const [cut, copy, more] = await menu.getItems();
+ *
+ * expect(await copy.isDisabled()).toBe(true);
+ * await more.openSubmenu();
+ * await more.clickSubmenuItem({ text: 'Duplicate' });
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrContextMenuItemHarness extends ComponentHarness {
+    /** The class the item paints on its host. */
+    static hostSelector: string;
+    /** Build a predicate that narrows the query. */
+    static with(options?: WrContextMenuItemHarnessFilters): HarnessPredicate<WrContextMenuItemHarness>;
+    /**
+     * The item's label, trimmed.
+     *
+     * Read from the label span, not from the host: a registered icon is written in
+     * with `innerHTML`, so an icon carrying a `<title>` would otherwise become
+     * part of the answer.
+     */
+    getText(): Promise<string>;
+    /** The role the item announces — `menuitem`. */
+    getRole(): Promise<string | null>;
+    /**
+     * Whether the item refuses activation.
+     *
+     * `aria-disabled`, not the `--disabled` modifier class: both are there, and
+     * this is the one a screen reader is told.
+     */
+    isDisabled(): Promise<boolean>;
+    /**
+     * Whether the item owns a nested submenu.
+     *
+     * Read from `aria-haspopup`, not from the `--has-submenu` class or the
+     * `[submenu]` input: the input is always BOUND (it takes a
+     * `<wr-context-menu>` reference), so it never reaches the DOM, and the ARIA
+     * property is what announces the item as a drill-down.
+     */
+    hasSubmenu(): Promise<boolean>;
+    /** Whether this item's submenu is showing, per `aria-expanded`. */
+    isSubmenuOpen(): Promise<boolean>;
+    /** Whether the item shows a leading icon. */
+    hasIcon(): Promise<boolean>;
+    /** The leading icon's registered name, or `null` when the item has no icon. */
+    getIconName(): Promise<string | null>;
+    /**
+     * Whether the item holds focus.
+     *
+     * Worth asking, because nothing in this component ever puts it there: unlike
+     * `<wr-dropdown-menu>`, a context menu does not focus its first item on open
+     * and has no arrow-key cursor between items. Focus lands on an item when
+     * something sends it a key — which every keyboard method here does, since the
+     * CDK focuses an element before typing into it.
+     */
+    isFocused(): Promise<boolean>;
+    /**
+     * Click the item. A disabled item throws instead.
+     *
+     * Refusing is the only honest answer. A browser never delivers the click at all:
+     * `pointer-events: none` on the `--disabled` modifier takes the row out of the
+     * hit test. jsdom loads no stylesheets, so a click dispatched here DOES land on
+     * the host, and while the component's own handler refuses it (a disabled item
+     * dismisses nothing), the consumer's `(click)` on that same host is a separate
+     * listener and runs — so the spec would record an activation that cannot happen
+     * in a browser. Assert `isDisabled()` instead.
+     *
+     * Activating a LEAF item dismisses the whole chain, root menu included. An item
+     * that owns a submenu is not a leaf: clicking it does nothing at all (hover or
+     * `openSubmenu()` is how it opens).
+     */
+    click(): Promise<void>;
+    /**
+     * Press Enter on the item — the keyboard equivalent of a click, and the route
+     * a spec should prefer, since it needs no hit test.
+     *
+     * Deliberately does NOT refuse a disabled item the way `click()` does: the
+     * component guards the keyboard path itself, so the key can be sent honestly
+     * and a spec can assert that nothing happened. On an item that owns a submenu
+     * this OPENS the submenu rather than activating the row, which is the APG
+     * behaviour — activating it would close the menu and leave the submenu
+     * unreachable from the keyboard.
+     */
+    activateByKeyboard(): Promise<void>;
+    /**
+     * Open this item's submenu with the right arrow and wait until it says so.
+     *
+     * The keyboard, not the pointer: it opens with no delay (hover waits out
+     * 120ms — `openSubmenuByHover()` covers that path) and needs no coordinates,
+     * which jsdom could not supply anyway. Sending the key focuses the item first,
+     * exactly as a roving cursor would have.
+     */
+    openSubmenu(timeout?: number): Promise<void>;
+    /**
+     * Open this item's submenu by resting the pointer on it, the gesture a mouse
+     * user actually makes, and wait out the hover delay.
+     */
+    openSubmenuByHover(timeout?: number): Promise<void>;
+    /** Close this item's submenu with the left arrow. An item without one open is left alone. */
+    closeSubmenu(timeout?: number): Promise<void>;
+    /**
+     * The items in THIS item's submenu, in DOM order.
+     *
+     * Throws while the submenu is shut, and while the item owns none: both would
+     * otherwise answer with an empty array, which reads like a submenu that
+     * rendered nothing and fails somewhere else entirely.
+     */
+    getSubmenuItems(filters?: WrContextMenuItemHarnessFilters): Promise<WrContextMenuItemHarness[]>;
+    /** The labels of the items in this item's submenu, in DOM order. */
+    getSubmenuItemTexts(): Promise<string[]>;
+    /**
+     * Open the submenu if it is shut, then click the first item in it matching the
+     * filters.
+     *
+     * Picking a leaf dismisses the whole chain — this item's submenu and the root
+     * menu with it.
+     */
+    clickSubmenuItem(filters: WrContextMenuItemHarnessFilters): Promise<void>;
+    /**
+     * A loader scoped to THIS item's submenu pane.
+     *
+     * Scoped by the published id rather than by `.wr-context-menu`: every pane in
+     * the chain — the root menu and each open submenu — carries that class in one
+     * shared overlay container, so a class query would answer with whichever
+     * opened first.
+     */
+    private submenuLoader;
+    /** The id this item publishes as `aria-controls`, which its open submenu carries. */
+    private submenuId;
+    /** Fail early, and by name, when the item is not a drill-down at all. */
+    private assertHasSubmenu;
+    /** Poll until `isSubmenuOpen()` reports `open`, and say whether it did. */
+    private settled;
+}
+
+/**
+ * @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 `[wrContextMenu]` — the right-click target, and the menu it
+ * opens.
+ *
+ * The harness matches the TARGET, because that is the only part of a context
+ * menu in the fixture: `<wr-context-menu>` renders nothing of its own (it hands
+ * over an `<ng-template>` and hides its host), and the menu is portalled into the
+ * overlay container, a sibling of the whole app. So every item is read through
+ * the document root, scoped by the `aria-controls` id the target publishes while
+ * its menu is up — which is what keeps two menus on one page from answering with
+ * each other's items, and what keeps a re-opened menu from answering with the one
+ * still playing its exit animation.
+ *
+ * That scoped loader is also this harness's CONTENT loader, so
+ * `menu.getHarness(…)` resolves inside THIS menu: a component the consumer
+ * projected into the menu is reachable without the spec ever touching the
+ * overlay.
+ *
+ * **How it differs from `WrDropdownHarness`, its closest sibling.**
+ *
+ * - The gesture is a real `contextmenu` event, not a click — `open()` sends one,
+ *   and `openByLongPress()` covers the touch path. There is no toggle: a second
+ *   right-click re-opens the menu at the new pointer position.
+ * - Activating an item DISMISSES the menu (a dropdown's stays up), so
+ *   `clickItem()` leaves it closed.
+ * - Submenus are a first-class input here rather than a nested trigger, so they
+ *   are driven from {@link WrContextMenuItemHarness}.
+ * - The menu never takes focus: nothing focuses the first item and there is no
+ *   arrow-key cursor between items, so there is no `getFocusedItemText()` to ask
+ *   — see `WrContextMenuItemHarness.isFocused()`.
+ *
+ * **Timing.** The waits are real: a 500ms `setTimeout` for the long-press hold and
+ * another 220ms one for the exit animation the pane is held alive through, plus the
+ * outside-press window above — that one is a `performance.now()` comparison against
+ * the moment the menu opened rather than a timer, so only wall-clock time gets past
+ * it. The methods that must sit out real time say so; a spec on fake timers should
+ * drive the clock itself and read `isOpen()`.
+ *
+ * @example
+ * ```ts
+ * const menu = await loader.getHarness(WrContextMenuHarness.with({ text: 'Right-click me' }));
+ *
+ * await menu.open();
+ * expect(await menu.getItemTexts()).toEqual(['Cut', 'Copy', 'More']);
+ *
+ * await menu.clickItem({ text: 'Cut' });
+ * expect(await menu.isOpen()).toBe(false);
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrContextMenuHarness extends ContentContainerComponentHarness {
+    /** The directive's host — whatever element the consumer put `[wrContextMenu]` on. */
+    static hostSelector: string;
+    /** Build a predicate that narrows the query. */
+    static with(options?: WrContextMenuHarnessFilters): HarnessPredicate<WrContextMenuHarness>;
+    /** The target's own visible text — the content that gets right-clicked. */
+    getTargetText(): Promise<string>;
+    /**
+     * Whether this target's menu is showing.
+     *
+     * Read from the target rather than from the overlay, and that is the whole
+     * point: a closed menu's pane stays in the DOM for its exit animation, while
+     * the reference is dropped the instant the close begins. Asking the DOM
+     * "is a menu present" would answer `true` for a quarter of a second after every
+     * dismissal.
+     *
+     * So the answer is only as good as the directive's claim on `aria-controls`:
+     * put `[wrContextMenu]` on an element that publishes one of its own and the two
+     * fight over a single attribute.
+     */
+    isOpen(): Promise<boolean>;
+    /** The role the menu announces — `menu`. Throws while no menu is open. */
+    getMenuRole(): Promise<string | null>;
+    /**
+     * Everything the open menu renders as text, runs of whitespace collapsed.
+     *
+     * Wider than `getItemTexts()` on purpose: `<wr-context-menu>` projects whatever
+     * it is given, so a section heading or any other markup a consumer put between
+     * the items shows up here and in no item harness. Dividers contribute nothing —
+     * they render no text.
+     *
+     * Expect to match a FRAGMENT of this rather than the whole of it: Angular
+     * strips the whitespace between elements at compile time, so the labels run
+     * together (`'Pick oneAppleBanana'`). The collapsing here only tidies newlines
+     * inside a single block of projected text.
+     */
+    getMenuText(): Promise<string>;
+    /**
+     * Open the menu by right-clicking the target, the gesture the directive
+     * actually listens for (`contextmenu`, which is also what Shift+F10 sends).
+     *
+     * An already-open menu is left alone — `rightClick()` is the raw gesture if
+     * what you want is the re-open.
+     *
+     * Note for a spec with two targets: a `contextmenu` event anywhere is an
+     * outside pointer event for every OTHER open menu, so this dismisses them on
+     * the way in. `openByLongPress()` is the route that does not.
+     */
+    open(): Promise<void>;
+    /**
+     * Send a `contextmenu` to the target whatever state the menu is in.
+     *
+     * On an open menu this re-opens it at the new pointer position — the previous
+     * pane is dismissed and a fresh one takes its place, which is why the harness
+     * scopes by a per-open id rather than by class: for the length of the exit
+     * animation both are in the container, the dying one first.
+     *
+     * The coordinates the CDK requires are all zeros, and meaningless: jsdom has no
+     * layout. Nothing here needs them — the event is dispatched on the element
+     * itself, no hit test involved.
+     */
+    rightClick(): Promise<void>;
+    /**
+     * Open the menu with a touch long-press — hold a non-mouse pointer on the
+     * target for 500ms — and wait until it is up.
+     *
+     * Worth its own method rather than an argument to `open()`, for the reason the
+     * dropdown has `openByKeyboard()`: it is the only way to get TWO context menus
+     * open at once. The press emits no `click` / `auxclick` / `contextmenu`, so it
+     * is not an outside press for anyone else's menu, while a right-click is.
+     *
+     * The pointer fields the directive reads are assigned onto a synthetic event:
+     * what matters is a primary pointer that is not a mouse. Movement beyond 10px,
+     * a scroll, or an early lift cancels the hold in the component — none of which
+     * this does.
+     */
+    openByLongPress(timeout?: number): Promise<void>;
+    /**
+     * Dismiss the menu with Escape and wait until its pane has left the DOM.
+     *
+     * Escape is delivered by the CDK's keyboard dispatcher to the TOP-MOST overlay,
+     * so with a later menu (or any other overlay) open on top, this one keeps
+     * waiting its turn — that is what the throw below is about. The wait covers the
+     * 220ms exit animation, so a spec can assert afterwards that nothing lingers.
+     */
+    close(timeout?: number): Promise<void>;
+    /**
+     * Dismiss the menu by pressing outside it, the way a user gets rid of one, and
+     * wait until its pane has left the DOM.
+     *
+     * Sits out real time first: the directive ignores outside events for 200ms after
+     * opening, so the right-click that opened the menu cannot immediately close it
+     * again with its own trailing `auxclick`. The press then lands on the TARGET,
+     * which is outside the pane and therefore counts — the page background is not
+     * something a harness has a handle on. A target that carries a `(click)` of its
+     * own will see it fire, so assert on the dismissal rather than on that handler.
+     */
+    closeByOutsidePress(timeout?: number): Promise<void>;
+    /**
+     * The items in this menu, in DOM order.
+     *
+     * Only this menu's own: an open submenu is a separate pane, so its items are
+     * `WrContextMenuItemHarness.getSubmenuItems()`, not part of this list. Dividers
+     * are not items either.
+     *
+     * Throws while the menu is shut — the items do not exist anywhere until the
+     * portal is attached, and an empty array reads like a menu that rendered
+     * nothing.
+     */
+    getItems(filters?: WrContextMenuItemHarnessFilters): Promise<WrContextMenuItemHarness[]>;
+    /** The labels of this menu's items, in DOM order. */
+    getItemTexts(): Promise<string[]>;
+    /**
+     * How many separators this menu shows.
+     *
+     * Counted by `role="separator"` rather than by `.wr-context-menu-divider`, so a
+     * separator the consumer wrote themselves counts too — the role is what tells a
+     * screen reader where one group of items ends. A separator is never a member of
+     * `getItems()`.
+     */
+    getDividerCount(): Promise<number>;
+    /**
+     * Open the menu if it is shut, then click the first item matching the filters.
+     *
+     * Picking a leaf DISMISSES the menu — unlike a dropdown, which stays up. The
+     * dismissal is reported at once (the target drops its reference synchronously),
+     * while the pane plays its exit animation for another 220ms.
+     */
+    clickItem(filters: WrContextMenuItemHarnessFilters): Promise<void>;
+    /**
+     * A loader scoped to THIS target's menu — the content loader every
+     * `HarnessLoader` method on this class runs through, `getItems()` included.
+     *
+     * Scoped by the published id rather than by `.wr-context-menu`: the overlay
+     * container is shared by every pane on the page, so a bare class query would
+     * answer with whichever menu opened first.
+     */
+    protected getRootHarnessLoader(): Promise<HarnessLoader>;
+    /** This target's menu element in the overlay. */
+    private menu;
+    /** Every element inside THIS menu matching the selector. */
+    private inMenuAll;
+    /** The id the target publishes as `aria-controls`, which its open menu carries. */
+    private menuId;
+    /** Poll until the pane with this id has been disposed. */
+    private waitUntilGone;
+    /** Poll until `isOpen()` reports `open`, and say whether it did. */
+    private settled;
+}
+
+export { WrContextMenuHarness, WrContextMenuItemHarness };
+export type { WrContextMenuHarnessFilters, WrContextMenuItemHarnessFilters };