@jbrowse/core 4.3.0 → 5.0.0-beta.1

package/esm/ui/parseError.d.ts

@@ -0,0 +1,4 @@
+export declare function parseError(str: string): {
+    snapshotValue: unknown;
+    message: string;
+};

package/esm/ui/parseError.js

@@ -0,0 +1,18 @@
+function tryParseJson(str) {
+    try {
+        return JSON.parse(str);
+    }
+    catch {
+        return str;
+    }
+}
+export function parseError(str) {
+    let snapshotValue;
+    let message = '';
+    const match = /(?:at path "([^"]*)" )?snapshot `([^`]*)` is not assignable/.exec(str);
+    if (match) {
+        snapshotValue = tryParseJson(match[2]);
+        message = match[1] ? `Snapshot at path "${match[1]}":` : 'Snapshot:';
+    }
+    return { snapshotValue, message };
+}

package/esm/ui/persistentScrollbarStyle.d.ts

@@ -0,0 +1,49 @@
+import type { JBrowseStyleTheme } from './styleTheme.ts';
+/**
+ * Makes a scroll container's native scrollbar always visible.
+ *
+ * macOS (and iOS, and Android) browsers default to *overlay* scrollbars: zero
+ * layout width, drawn only while a scroll is in flight, faded out a moment
+ * later. A stack of views taller than the window then offers nothing to grab
+ * and no hint that it scrolls at all. `scrollbar-gutter` cannot fix that — it
+ * is defined to have no effect on overlay scrollbars — but giving
+ * `::-webkit-scrollbar` an explicit width does: Chromium and Safari switch that
+ * container to a classic, always-drawn, space-occupying scrollbar.
+ *
+ * Deliberately no `scrollbar-gutter: stable`, which would work once the lane is
+ * classic: it reserves the lane whether or not anything overflows, so a
+ * container showing one short view would pay 12px for a scrollbar it never
+ * draws. The lane appearing is the signal, so it has to mean something — which
+ * puts the burden on the container to overflow only when it has content to
+ * scroll to, rather than by trailing space it renders for its own reasons.
+ *
+ * Deliberately no `scrollbar-width`/`scrollbar-color`: in Chromium the standard
+ * properties win over the `::-webkit-` pseudo-elements and put the overlay
+ * behavior back. Firefox on macOS ignores both approaches and follows the OS
+ * "Show scroll bars" setting; there is no CSS that overrides it.
+ *
+ * Thumb geometry matches {@link VerticalScrollbar}, the scrollbar the
+ * canvas-backed displays draw for themselves, so the two read as one control.
+ */
+export declare const persistentScrollbarStyle: (theme: JBrowseStyleTheme) => {
+    readonly '&::-webkit-scrollbar': {
+        readonly width: 12;
+        readonly height: 12;
+    };
+    readonly '&::-webkit-scrollbar-track': {
+        readonly background: 'transparent';
+    };
+    readonly '&::-webkit-scrollbar-thumb': {
+        readonly background: string;
+        readonly borderRadius: number;
+        readonly border: "3px solid transparent";
+        readonly backgroundClip: 'content-box';
+    };
+    readonly '&::-webkit-scrollbar-thumb:hover': {
+        readonly background: string;
+        readonly backgroundClip: 'content-box';
+    };
+    readonly '&::-webkit-scrollbar-corner': {
+        readonly background: 'transparent';
+    };
+};

package/esm/ui/persistentScrollbarStyle.js

@@ -0,0 +1,53 @@
+const LANE_WIDTH = 12;
+const THUMB_INSET = 3;
+/**
+ * Makes a scroll container's native scrollbar always visible.
+ *
+ * macOS (and iOS, and Android) browsers default to *overlay* scrollbars: zero
+ * layout width, drawn only while a scroll is in flight, faded out a moment
+ * later. A stack of views taller than the window then offers nothing to grab
+ * and no hint that it scrolls at all. `scrollbar-gutter` cannot fix that — it
+ * is defined to have no effect on overlay scrollbars — but giving
+ * `::-webkit-scrollbar` an explicit width does: Chromium and Safari switch that
+ * container to a classic, always-drawn, space-occupying scrollbar.
+ *
+ * Deliberately no `scrollbar-gutter: stable`, which would work once the lane is
+ * classic: it reserves the lane whether or not anything overflows, so a
+ * container showing one short view would pay 12px for a scrollbar it never
+ * draws. The lane appearing is the signal, so it has to mean something — which
+ * puts the burden on the container to overflow only when it has content to
+ * scroll to, rather than by trailing space it renders for its own reasons.
+ *
+ * Deliberately no `scrollbar-width`/`scrollbar-color`: in Chromium the standard
+ * properties win over the `::-webkit-` pseudo-elements and put the overlay
+ * behavior back. Firefox on macOS ignores both approaches and follows the OS
+ * "Show scroll bars" setting; there is no CSS that overrides it.
+ *
+ * Thumb geometry matches {@link VerticalScrollbar}, the scrollbar the
+ * canvas-backed displays draw for themselves, so the two read as one control.
+ */
+export const persistentScrollbarStyle = (theme) => ({
+    '&::-webkit-scrollbar': {
+        width: LANE_WIDTH,
+        height: LANE_WIDTH,
+    },
+    '&::-webkit-scrollbar-track': {
+        background: 'transparent',
+    },
+    '&::-webkit-scrollbar-thumb': {
+        background: theme.palette.action.disabled,
+        borderRadius: LANE_WIDTH / 2,
+        // paints the thumb inside a transparent border so the lane keeps its
+        // full hit area while the visible thumb stays the same 6px the
+        // in-display scrollbar uses
+        border: `${THUMB_INSET}px solid transparent`,
+        backgroundClip: 'content-box',
+    },
+    '&::-webkit-scrollbar-thumb:hover': {
+        background: theme.palette.action.active,
+        backgroundClip: 'content-box',
+    },
+    '&::-webkit-scrollbar-corner': {
+        background: 'transparent',
+    },
+});

package/esm/ui/promotableMenuItems.d.ts

@@ -0,0 +1,19 @@
+import type { Pin } from '../configuration/promotablePin.ts';
+import type { CheckboxMenuItem, RadioMenuItem } from './MenuTypes.ts';
+import type { RadioOption, SettingRowOptions } from './toggleMenuItems.ts';
+/** #menuBuilder promotableToggleItem | `checkboxItem` plus an apply-to-open-tracks pin */
+export declare function promotableToggleItem({ label, checked, onToggle, pin, ...opts }: {
+    label: string;
+    checked: boolean;
+    onToggle: () => void;
+    pin: Pin;
+} & SettingRowOptions): CheckboxMenuItem;
+/** #menuBuilder promotableRadioItem | `radioItem` plus an apply-to-open-tracks pin */
+export declare function promotableRadioItem({ label, checked, onClick, pin, ...opts }: {
+    label: string;
+    checked: boolean;
+    onClick: () => void;
+    pin?: Pin;
+} & SettingRowOptions): RadioMenuItem;
+/** #menuBuilder promotableRadioItems | `radioItems` plus a pin per option, from a factory over the value */
+export declare function promotableRadioItems<T extends string>(options: readonly RadioOption<T>[], current: T | undefined, setMode: (m: T) => void, pin: (value: T) => Pin): RadioMenuItem[];

package/esm/ui/promotableMenuItems.js

@@ -0,0 +1,89 @@
+import { checkboxItem, radioItem, radioItems } from './toggleMenuItems.js';
+// Every builder here describes the trailing pin (`pin`) rather than
+// rendering it. That is what keeps this module — and therefore every state
+// model and menu file that calls it — free of React and of MUI's
+// ToggleButton/Tooltip. `menuItemAdornment.tsx` turns the description into
+// `PinAdornment` at the point the menu is drawn. See
+// reference/EAGER_BUNDLE.md; `menuItems.purity.test.ts` holds it.
+//
+// Each is the plain builder in `toggleMenuItems.ts` plus a pin, and each is
+// written that way — `checkboxItem` / `radioItems` build the row — so the
+// promotable and plain forms of a row can differ only by the pin.
+// A promotable setting as one native checkbox menu row: the value toggles the
+// track (inheriting native hover/sizing/keyboard), and a trailing pin
+// (endAdornment) applies this value to every open track of the display type,
+// offering the display-type default as its snackbar's one action. Always shown
+// so the capability is discoverable.
+//
+// **The row itself is `checkboxItem`'s**, so the two builders can only ever
+// differ by the pin. They used to be two literals, and had already drifted: this
+// one accepted `helpText` and `keepMenuOpen` while silently dropping `disabled`
+// and `disabledHelpText`, so a promotable row could not be greyed out the way
+// its plain sibling could. Sharing the body is also what makes a future
+// change to what a checkbox row *is* reach both — the failure `checkboxItem`'s
+// own comment records is a menu regressing by omission.
+//
+// `keepMenuOpen` is left unset by default, so `CascadingMenu` keeps the row open
+// by its checkbox type: these rows only write a setting, users flip several in
+// one visit, and the menu is an observer so the ticks and pins move live. A row
+// whose click opens a dialog instead (colorBy's "Tag...") passes false.
+/** #menuBuilder promotableToggleItem | `checkboxItem` plus an apply-to-open-tracks pin */
+export function promotableToggleItem({ label, checked, onToggle, pin, ...opts }) {
+    return {
+        ...checkboxItem(label, checked, onToggle, opts),
+        pin: { control: pin, label },
+    };
+}
+// ONE radio row of a promotable-value group — the escape hatch, for a group the
+// plural builder below can't express. **Reach for `promotableRadioItems` first**:
+// every option in a group has to get a pin, and hand-naming the rows is what
+// leaves one without.
+//
+// The rows that genuinely need this: `pin` is optional here, for a row with no
+// single value to promote yet (the colorBy "Tag..." row before a tag is picked)
+// or a display whose slot isn't promotable at all (the shared colorBy menu on
+// gwas/variants); and the alignments size presets, whose group is gated row by
+// row (`needsContent`) and mixes in a non-promotable "Custom..." peer.
+//
+// **The row itself is `radioItem`'s**, for the reason `promotableToggleItem`'s
+// is `checkboxItem`'s: it was a second literal, and it had drifted the same way
+// its checkbox sibling had — naming `helpText`/`keepMenuOpen` by hand and so
+// silently dropping `disabled` and `disabledHelpText`, which the
+// alignments size presets have to bolt back on afterwards (`needsContent`).
+/** #menuBuilder promotableRadioItem | `radioItem` plus an apply-to-open-tracks pin */
+export function promotableRadioItem({ label, checked, onClick, pin, ...opts }) {
+    return {
+        ...radioItem(label, checked, onClick, opts),
+        ...(pin && {
+            pin: { control: pin, label },
+        }),
+    };
+}
+// A whole promotable radio group: `radioItems` plus one pin per option. The
+// plural form of the builder above, and the one to reach for on a group whose
+// options differ only in their value — which is all four of them today
+// (`heightMode`, `displayMode`, `subfeatureLabels`, `sashimiArcsMode`).
+//
+// **Every option in a group gets a pin, the `promotedBase` value included** —
+// once a non-base value is promoted, pinning the base back is the only per-value
+// way to undo it from its own row, and a radio group with one row silently
+// missing its trailing control reads as a bug. Building the group here is what
+// makes that structural instead of a rule to remember: `sashimiArcsMode`'s base
+// looked unpinnable precisely because each row had been named by hand. Prefer
+// this over `.map(promotableRadioItem)` whenever the pin is a function of the
+// option's value.
+//
+// `pin` is a factory rather than an array so it can't be a row short. Pass
+// `value => makePin(self, slot, value)`, or a model member of that shape where
+// the menu module is handed a duck-typed model (alignments).
+//
+// The rows are `radioItems`' own, so the promotable and plain groups can't drift
+// on anything but the pin. `radioItems` maps `options` in order, which is what
+// lets each row be paired back to the option that built it.
+/** #menuBuilder promotableRadioItems | `radioItems` plus a pin per option, from a factory over the value */
+export function promotableRadioItems(options, current, setMode, pin) {
+    return radioItems(options, current, setMode).map((item, i) => {
+        const { value, label } = options[i];
+        return { ...item, pin: { control: pin(value), label } };
+    });
+}

package/esm/ui/promotablePinCoverage.d.ts

@@ -0,0 +1,44 @@
+import type { ResolvableDisplay } from '../configuration/promotableResolve.ts';
+import type { MenuItem } from './MenuTypes.ts';
+import type { IAnyType } from '@jbrowse/mobx-state-tree';
+/**
+ * The registered display types whose config schema declares a promotable slot,
+ * sorted — the set a pin-coverage check has to reach, answered off the
+ * `DisplayType`s themselves before anything is opened.
+ *
+ * The other half of the same gap `promotableSlotsWithoutPin` covers, and the
+ * half that has no symptom at all: that function reports on a display it was
+ * *given*, so a display type no fixture ever opens is not checked and does not
+ * say so. Six display types declaring `showLegend` sat outside the check's
+ * reach with nothing recording it.
+ *
+ * Takes the display types rather than a `PluginManager`, so core doesn't have
+ * to name a plugin registry to answer a question about config schemas.
+ */
+export declare function displayTypesWithPromotableSlots(displayTypes: readonly {
+    name: string;
+    configSchema: IAnyType;
+}[]): string[];
+/**
+ * Every promotable slot some row of `items` carries a pin for, submenus
+ * included.
+ *
+ * Reads `pin.control.slot` and nothing else. A raw `endAdornment` is
+ * deliberately not counted: it is an arbitrary element (synteny's colour
+ * swatch), so it cannot say which slot it promotes, and a pin built by hand
+ * rather than through `promotableToggleItem`/`promotableRadioItem` is a thing to
+ * find, not to accept.
+ */
+export declare function pinnedSlots(items: MenuItem[]): Set<string>;
+/**
+ * A display's promotable slots that its own track menu offers no pin for,
+ * sorted. Empty is the healthy answer.
+ *
+ * Takes the built menu rather than calling `trackMenuItems()` itself, because
+ * what a menu contains depends on the display's current state — a row can be
+ * gated on a rendering type (wiggle line width), on a parent toggle (the sashimi
+ * options), or on data having arrived. A caller that wants the whole surface has
+ * to drive the display into the states that reveal it, and that is a decision
+ * this function should not make silently.
+ */
+export declare function promotableSlotsWithoutPin(display: ResolvableDisplay, menuItems: MenuItem[]): string[];

package/esm/ui/promotablePinCoverage.js

@@ -0,0 +1,87 @@
+/**
+ * @module
+ * The read side of the promotable pin: given a display, which of its promotable
+ * slots its track menu actually offers a pin for.
+ *
+ * This exists because the two halves of the feature are declared in different
+ * places and nothing joins them. Declaring `promotedBase` is a **schema** fact
+ * that travels down `baseConfiguration` to every subclass; the pin is a **menu**
+ * fact, built by whichever `trackMenuItems()` happens to construct a row for that
+ * slot. A display that inherits the slot and curates its own menu therefore ends
+ * up with a promotable slot that has no pin anywhere — and since a promoted default
+ * is keyed by *display type*, no other display's pin can write its key either, so
+ * the slot resolves to `promotedBase` forever unless a track customizes it.
+ *
+ * Nothing throws, nothing renders differently, and the config docs go on
+ * advertising the setting as having a session-wide default. The state was tracked
+ * by hand in `agent-docs/reference/DISPLAY_TYPE_DEFAULTS.md` and drifted twice
+ * before this was written — once gaining a row for a slot that had been deleted,
+ * once missing a slot that had been added.
+ *
+ * `products/jbrowse-web/src/tests/PromotablePinCoverage.test.ts` is the guard: it
+ * opens one display of every type that declares a promotable slot and holds the
+ * result against a baseline.
+ */
+import { promotableSlotNames } from '../configuration/promotableSlots.js';
+/**
+ * The registered display types whose config schema declares a promotable slot,
+ * sorted — the set a pin-coverage check has to reach, answered off the
+ * `DisplayType`s themselves before anything is opened.
+ *
+ * The other half of the same gap `promotableSlotsWithoutPin` covers, and the
+ * half that has no symptom at all: that function reports on a display it was
+ * *given*, so a display type no fixture ever opens is not checked and does not
+ * say so. Six display types declaring `showLegend` sat outside the check's
+ * reach with nothing recording it.
+ *
+ * Takes the display types rather than a `PluginManager`, so core doesn't have
+ * to name a plugin registry to answer a question about config schemas.
+ */
+export function displayTypesWithPromotableSlots(displayTypes) {
+    return displayTypes
+        .filter(d => promotableSlotNames(d.configSchema).size > 0)
+        .map(d => d.name)
+        .sort((a, b) => a.localeCompare(b));
+}
+/**
+ * Every promotable slot some row of `items` carries a pin for, submenus
+ * included.
+ *
+ * Reads `pin.control.slot` and nothing else. A raw `endAdornment` is
+ * deliberately not counted: it is an arbitrary element (synteny's colour
+ * swatch), so it cannot say which slot it promotes, and a pin built by hand
+ * rather than through `promotableToggleItem`/`promotableRadioItem` is a thing to
+ * find, not to accept.
+ */
+export function pinnedSlots(items) {
+    const found = new Set();
+    const walk = (list) => {
+        for (const item of list) {
+            if ('pin' in item && item.pin) {
+                found.add(item.pin.control.slot);
+            }
+            if ('subMenu' in item) {
+                walk(item.subMenu);
+            }
+        }
+    };
+    walk(items);
+    return found;
+}
+/**
+ * A display's promotable slots that its own track menu offers no pin for,
+ * sorted. Empty is the healthy answer.
+ *
+ * Takes the built menu rather than calling `trackMenuItems()` itself, because
+ * what a menu contains depends on the display's current state — a row can be
+ * gated on a rendering type (wiggle line width), on a parent toggle (the sashimi
+ * options), or on data having arrived. A caller that wants the whole surface has
+ * to drive the display into the states that reveal it, and that is a decision
+ * this function should not make silently.
+ */
+export function promotableSlotsWithoutPin(display, menuItems) {
+    const pinned = pinnedSlots(menuItems);
+    return [...promotableSlotNames(display.configuration)]
+        .filter(slot => !pinned.has(slot))
+        .sort((a, b) => a.localeCompare(b));
+}

package/esm/ui/radioSubMenu.d.ts

@@ -0,0 +1,33 @@
+import type { MenuItem } from './MenuTypes.ts';
+import type React from 'react';
+/**
+ * Build a radio submenu from a `[value, label]` option table keyed on the
+ * current `value`. Lets a display keep one option table as the single source of
+ * truth for both its config enumeration and its track menu, so the two can't
+ * drift. Generic over the value's string-literal union. `extraItems` are
+ * appended after the radios (e.g. a related checkbox) within the same submenu.
+ *
+ * Every display has a submenu of this shape naming the one thing it draws —
+ * wiggle's "Plot type", MAF's "Row coloring", Hi-C's "Color scheme", the arc
+ * display's "Display mode". The labels stay display-specific (they name
+ * genuinely different choices); the construction is shared so a hand-rolled
+ * copy can't forget that a settings row keeps the menu open.
+ *
+ * React-free: `React.ElementType` is a type-only import, so this stays inside
+ * the `menuItems.ts` purity boundary.
+ */
+/** #menuBuilder makeRadioSubMenu | a radio group wrapped in a submenu row */
+export declare function makeRadioSubMenu<T extends string>(opts: {
+    label: string;
+    icon?: React.ElementType;
+    value: T;
+    onChange: (value: T) => void;
+    options: readonly (readonly [T, string])[];
+    extraItems?: MenuItem[];
+    /**
+     * Prose for the group, on the row that opens it. One "?" here rather than one
+     * per radio, which is where a group whose options differ by a word each would
+     * otherwise repeat itself three times.
+     */
+    helpText?: string;
+}): MenuItem;

package/esm/ui/radioSubMenu.js

@@ -0,0 +1,32 @@
+import { radioItems } from './toggleMenuItems.js';
+/**
+ * Build a radio submenu from a `[value, label]` option table keyed on the
+ * current `value`. Lets a display keep one option table as the single source of
+ * truth for both its config enumeration and its track menu, so the two can't
+ * drift. Generic over the value's string-literal union. `extraItems` are
+ * appended after the radios (e.g. a related checkbox) within the same submenu.
+ *
+ * Every display has a submenu of this shape naming the one thing it draws —
+ * wiggle's "Plot type", MAF's "Row coloring", Hi-C's "Color scheme", the arc
+ * display's "Display mode". The labels stay display-specific (they name
+ * genuinely different choices); the construction is shared so a hand-rolled
+ * copy can't forget that a settings row keeps the menu open.
+ *
+ * React-free: `React.ElementType` is a type-only import, so this stays inside
+ * the `menuItems.ts` purity boundary.
+ */
+/** #menuBuilder makeRadioSubMenu | a radio group wrapped in a submenu row */
+export function makeRadioSubMenu(opts) {
+    const { label, icon, value, onChange, options, extraItems = [] } = opts;
+    return {
+        label,
+        icon,
+        helpText: opts.helpText,
+        subMenu: [
+            // via radioItems so these keep the menu open like every other
+            // setting row — a plot type is usually picked by trying a couple
+            ...radioItems(options.map(([value, label]) => ({ value, label })), value, onChange),
+            ...extraItems,
+        ],
+    };
+}

package/esm/ui/react-colorful.js

@@ -1,4 +1,8 @@
-import e, { useRef as r, useMemo as t, useEffect as o, useState as a, useCallback as l, useLayoutEffect as n, } from 'react';
+/* eslint-disable */
+// @ts-nocheck
+// vendored (e.g. copied into our source tree) because the tooling picks up "import" statements that confuse jest, could confuse other consumers of our modules
+// copy of react-colorful/dist/index.esmodule.js
+import e, { useState as a, useCallback as l, useLayoutEffect as n, useEffect as o, useRef as r, useMemo as t, } from 'react';
 function s() {
     return (s =
         Object.assign ||

package/esm/ui/replaceViewAction.d.ts

@@ -0,0 +1,31 @@
+import type { AbstractViewContainer, AbstractViewModel } from '../util/types/index.ts';
+import type { SubmitFormProps } from './SubmitForm.tsx';
+/**
+ * The two destinations a launch dialog offers, as `SubmitDialog` props: Submit
+ * opens the launched view in a new one, and a second button puts it in the slot
+ * the launching view occupies.
+ *
+ * Every launcher anchored on what a view is already showing — the synteny
+ * launches, "read vs ref", the derivative reconstruction — wants exactly this
+ * pair, and each had written the same four lines around
+ * {@link ReplaceCurrentViewButton}: the guard, the button, its disabled state,
+ * and the renaming of Submit that only makes sense once there are two buttons.
+ * The guard is the part worth having in one place; see {@link canReplaceView}
+ * for the case each copy got wrong.
+ *
+ * Spread it into the dialog *before* any explicit props, so a caller that words
+ * its own Submit differently still can:
+ *
+ * ```tsx
+ * <SubmitDialog
+ *   {...replaceViewAction({ session, sourceView, disabled, onReplace: launch })}
+ *   submitText="Open in new view"
+ * />
+ * ```
+ */
+export declare function replaceViewAction({ session, sourceView, disabled, onReplace, }: {
+    session: AbstractViewContainer;
+    sourceView: AbstractViewModel | undefined;
+    disabled?: boolean;
+    onReplace: (replacing: AbstractViewModel) => void;
+}): Pick<SubmitFormProps, 'submitText' | 'actions'>;

package/esm/ui/replaceViewAction.js

@@ -0,0 +1,39 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { canReplaceView } from '../util/types/index.js';
+import ReplaceCurrentViewButton from './ReplaceCurrentViewButton.js';
+/**
+ * The two destinations a launch dialog offers, as `SubmitDialog` props: Submit
+ * opens the launched view in a new one, and a second button puts it in the slot
+ * the launching view occupies.
+ *
+ * Every launcher anchored on what a view is already showing — the synteny
+ * launches, "read vs ref", the derivative reconstruction — wants exactly this
+ * pair, and each had written the same four lines around
+ * {@link ReplaceCurrentViewButton}: the guard, the button, its disabled state,
+ * and the renaming of Submit that only makes sense once there are two buttons.
+ * The guard is the part worth having in one place; see {@link canReplaceView}
+ * for the case each copy got wrong.
+ *
+ * Spread it into the dialog *before* any explicit props, so a caller that words
+ * its own Submit differently still can:
+ *
+ * ```tsx
+ * <SubmitDialog
+ *   {...replaceViewAction({ session, sourceView, disabled, onReplace: launch })}
+ *   submitText="Open in new view"
+ * />
+ * ```
+ */
+export function replaceViewAction({ session, sourceView, disabled, onReplace, }) {
+    return canReplaceView(session, sourceView)
+        ? {
+            // named only when there is a second way out to tell it apart from —
+            // otherwise Submit is the only button and "Submit" is what it has
+            // always said
+            submitText: 'Open in new view',
+            actions: (_jsx(ReplaceCurrentViewButton, { disabled: disabled, onClick: () => {
+                    onReplace(sourceView);
+                } })),
+        }
+        : {};
+}

package/esm/ui/rewriteExternalAnchors.d.ts

@@ -0,0 +1 @@
+export declare function rewriteExternalAnchors(el: HTMLElement): void;

package/esm/ui/rewriteExternalAnchors.js

@@ -0,0 +1,8 @@
+// Harden anchors in sanitized HTML: open in a new tab without leaking the
+// opener reference. Shared by the setHTML and dompurify sanitizer paths.
+export function rewriteExternalAnchors(el) {
+    for (const a of el.querySelectorAll('a')) {
+        a.setAttribute('rel', 'noopener noreferrer');
+        a.setAttribute('target', '_blank');
+    }
+}

package/esm/ui/scrollZoomLabels.d.ts

@@ -0,0 +1,17 @@
+/**
+ * The preference's name. One string, because it had four spellings across three
+ * headers and a menu, and a user who meets it twice has to recognize it as the
+ * same thing.
+ */
+export declare const SCROLL_ZOOM_LABEL = "Zoom on scroll";
+/**
+ * One paragraph doing two jobs: the control's tooltip and the menu item's help
+ * text. Short enough to hover, because it is the only explanation there is —
+ * nothing else on screen names the gesture.
+ *
+ * It names where the page still scrolls, which is the part users cannot guess:
+ * with this on, the wheel over a track is the view's, and no modifier takes it
+ * back — the browser turns shift+wheel into horizontal scroll, ctrl/meta+wheel
+ * is a trackpad pinch, and Firefox binds alt+wheel to history navigation.
+ */
+export declare const SCROLL_ZOOM_HELP = "The mouse wheel zooms over the tracks instead of scrolling the page; the view header above them still scrolls. ctrl+scroll (\u2318+scroll on a Mac) zooms either way. Applies to every view in the app.";

package/esm/ui/scrollZoomLabels.js

@@ -0,0 +1,22 @@
+// What every surface calls scroll-to-zoom, in a module with no React in it:
+// LinearGenomeView's `menuItems.ts` is evaluated eagerly and must not pull a
+// Material component graph in behind a pair of strings (see
+// agent-docs/reference/EAGER_BUNDLE.md). The control that renders them is
+// ScrollZoomToggle.
+/**
+ * The preference's name. One string, because it had four spellings across three
+ * headers and a menu, and a user who meets it twice has to recognize it as the
+ * same thing.
+ */
+export const SCROLL_ZOOM_LABEL = 'Zoom on scroll';
+/**
+ * One paragraph doing two jobs: the control's tooltip and the menu item's help
+ * text. Short enough to hover, because it is the only explanation there is —
+ * nothing else on screen names the gesture.
+ *
+ * It names where the page still scrolls, which is the part users cannot guess:
+ * with this on, the wheel over a track is the view's, and no modifier takes it
+ * back — the browser turns shift+wheel into horizontal scroll, ctrl/meta+wheel
+ * is a trackpad pinch, and Firefox binds alt+wheel to history navigation.
+ */
+export const SCROLL_ZOOM_HELP = 'The mouse wheel zooms over the tracks instead of scrolling the page; the view header above them still scrolls. ctrl+scroll (⌘+scroll on a Mac) zooms either way. Applies to every view in the app.';

package/esm/ui/showSubMenu.d.ts

@@ -0,0 +1,19 @@
+import type { MenuItem } from './MenuTypes.ts';
+/**
+ * The "Show..." submenu every display groups its visibility toggles under, and
+ * the empty-omit that goes with it: a display whose toggles are all
+ * inapplicable right now (wiggle in density mode with no cross hatches, a
+ * multi-row painting with no legend) drops the row rather than opening an empty
+ * submenu.
+ *
+ * One helper because this was eleven hand-written literals that had already
+ * drifted three ways: the wiggle family said `'Show'` where everyone else said
+ * `'Show...'`, only some set the redundant `type: 'subMenu'`, and only the
+ * wiggle family omitted the empty submenu.
+ *
+ * Not exported from `ui/menuItems.ts`: the icon is a value import, and that
+ * entry is the React-free one (see its header). Import this module directly —
+ * `@jbrowse/core/ui/showSubMenu` — which costs one icon rather than the
+ * `@jbrowse/core/ui` barrel's ~80 Material components.
+ */
+export declare function makeShowSubMenu(items: MenuItem[]): MenuItem[];

package/esm/ui/showSubMenu.js

@@ -0,0 +1,30 @@
+import VisibilityIcon from '@mui/icons-material/Visibility';
+/**
+ * The "Show..." submenu every display groups its visibility toggles under, and
+ * the empty-omit that goes with it: a display whose toggles are all
+ * inapplicable right now (wiggle in density mode with no cross hatches, a
+ * multi-row painting with no legend) drops the row rather than opening an empty
+ * submenu.
+ *
+ * One helper because this was eleven hand-written literals that had already
+ * drifted three ways: the wiggle family said `'Show'` where everyone else said
+ * `'Show...'`, only some set the redundant `type: 'subMenu'`, and only the
+ * wiggle family omitted the empty submenu.
+ *
+ * Not exported from `ui/menuItems.ts`: the icon is a value import, and that
+ * entry is the React-free one (see its header). Import this module directly —
+ * `@jbrowse/core/ui/showSubMenu` — which costs one icon rather than the
+ * `@jbrowse/core/ui` barrel's ~80 Material components.
+ */
+export function makeShowSubMenu(items) {
+    return items.length
+        ? [
+            {
+                label: 'Show...',
+                icon: VisibilityIcon,
+                type: 'subMenu',
+                subMenu: items,
+            },
+        ]
+        : [];
+}

package/esm/ui/sliderScale.d.ts

@@ -0,0 +1,6 @@
+export type SliderScale = 'linear' | 'log' | 'cubic';
+export declare function sliderScale(scale: SliderScale): {
+    toSlider: (n: number) => number;
+    fromSlider: (v: number) => number;
+    sliderStep: number | undefined;
+};