# LinearMultiRowFeatureDisplay Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see [pluggable elements](https://jbrowse.org/jb2-staging/docs/developer_guide/) for concepts. Provided by the `canvas` plugin. [View source](https://github.com/GMOD/jbrowse-components/blob/main/plugins/canvas/src/LinearMultiRowFeatureDisplay/model.ts). Multi-row interval painter (chromosome / ancestry painting). Partitions a single feature track into stacked rows by a feature attribute and paints each feature as a colored block on its row. GPU-rendered (WebGL/Canvas2D fallback) via the shared per-region lifecycle. Rows are a `sources` chain (discovered → layout-reconciled → subtree-filtered) and the left sidebar (labels + dendrogram + reorder) is the shared `TreeSidebarMixin`. The configuration slots for this model are documented on its [config schema page](../../config/linearmultirowfeaturedisplay). Members a composed model contributes are listed here too, so these tables are the whole surface. ## Properties | Member | Description | Defined by | | --- | --- | --- | | **type**
type: types.literal('LinearMultiRowFeatureDisplay') | | LinearMultiRowFeatureDisplay | | **configuration**
configuration: ConfigurationReference(configSchema) | | LinearMultiRowFeatureDisplay | | **hiddenCategories**
hiddenCategories: types.array(types.string) | Legend categories toggled off (by label). Features painted in a hidden category's color are dropped from both render paths and the hit-test. See `hiddenColors` / `toggleCategory`. | LinearMultiRowFeatureDisplay | | **id**
id: ElementId | | [BaseDisplay](../basedisplay#property-id) | | **layout**
layout: types.stripDefault(types.frozen<S[]>(), []) | | [TreeSidebarMixin](../treesidebarmixin#property-layout) | | **clusterTree**

clusterTree: types.stripDefault(types.maybe(types.string), undefined)

| | [TreeSidebarMixin](../treesidebarmixin#property-clustertree) | | **clusterProvenance**

clusterProvenance: types.stripDefault(
        types.maybe(types.frozen<ClusterProvenance>()),
        undefined,
      )

| What `clusterTree` was computed from — the locus and the settings. Set only for a tree this app computed; a supplied phylogeny (maf's `.nh`) leaves it undefined. Persisted with the tree so it survives a session snapshot, which is the case that most needs it: a shared link otherwise hands over a dendrogram with no way to learn its locus. | [TreeSidebarMixin](../treesidebarmixin#property-clusterprovenance) | | **treeAreaWidth**
treeAreaWidth: types.stripDefault(types.number, 80) | | [TreeSidebarMixin](../treesidebarmixin#property-treeareawidth) | | **subtreeFilter**

subtreeFilter: types.stripDefault(
        types.maybe(types.array(types.string)),
        undefined,
      )

| | [TreeSidebarMixin](../treesidebarmixin#property-subtreefilter) | | **runClustering**
runClustering: types.maybe(types.boolean) | Transient declarative launch spec, the same idea as `LinearGenomeView`'s `init`: a session or config sets this true and the real clustering RPC runs once automatically, with no dialog, as soon as the display reports itself ready. `setupRunClusteringAutorun` clears it afterwards, so a saved session never re-triggers.

Lives here rather than on each display because it is the trigger for a run whose *output* — `clusterTree`, `clusterProvenance`, `layout` — is this mixin's state. Three displays declared it identically, each with its own wrapper module that existed to code-split the clustering code and, along the way, hand-wrote the same six-member duck type of the display. Splitting inside the `run` callback does the same job and loads on a run rather than on every attach. What each run actually *is* stays per display, in that callback. | [TreeSidebarMixin](../treesidebarmixin#property-runclustering) | | **clusterRegion**
clusterRegion: types.maybe(types.string) | Where that run reads from, as a locstring (whitespace-separated for several). Clustering is region-scoped, so running it over the visible window feeds the estimator whatever happens to be on screen; naming the locus instead lets a session cluster on the signal and then show it against its context — otherwise a zoom the user has to perform in the right order. Cleared with `runClustering`, since it is that flag's argument and a locus left standing describes a run that is not coming. | [TreeSidebarMixin](../treesidebarmixin#property-clusterregion) | | **sortRowsBy**
sortRowsBy: types.maybe(types.frozen<RowSortSpec>()) | Transient declarative launch spec, the same idea as `runClustering`: set `{refName, pos}` to order the rows once by the value each carries at that genomic column — the session-expressible form of the right-click "Sort rows by ... here". `setupRowSortAutorun` applies it once the region containing it has loaded and then clears it, so the resulting `layout` persists but a saved session never re-sorts.

Where clustering orders rows by the whole region in view and `layout` states an order outright, only this one says "rank them here", which is what lets a figure open a cohort ranked at a candidate locus with the surrounding context still on screen. What the value at the column *is* stays per display, in its `sortRows` callback. | [TreeSidebarMixin](../treesidebarmixin#property-sortrowsby) | ## Volatiles | Member | Description | Defined by | | --- | --- | --- | | **rpcDataMap**
rpcDataMap: regionDataMap<MultiRowRegionData>('rpcDataMap') | | LinearMultiRowFeatureDisplay | | **prefersOffset**
prefersOffset: true | | LinearMultiRowFeatureDisplay | | **hoveredMultiRowFeature**
hoveredMultiRowFeature: undefined as MultiRowHit | undefined | The feature under the mouse, or undefined when not hovering a block. Pure hover identity — the cursor position that places the tooltip is component state, so moving inside one block doesn't invalidate this.

Named apart from the `hoveredFeature` getter it fills, because `BaseDisplay` declares that hook as a computed and MST refuses to instantiate a volatile over one. | LinearMultiRowFeatureDisplay | | **error**
error: undefined as unknown | | [BaseDisplay](../basedisplay#volatile-error) | | **statusMessage**
statusMessage: undefined as string | undefined | | [BaseDisplay](../basedisplay#volatile-statusmessage) | | **statusProgress**
statusProgress: undefined as number | undefined | determinate progress fraction [0,1] for the current status, or undefined when the in-flight phase is indeterminate. Set alongside `statusMessage` by `setStatusMessage`; a display that never shows a bar simply leaves it undefined. | [BaseDisplay](../basedisplay#volatile-statusprogress) | | **scrollTop**
scrollTop: 0 | | [TrackHeightMixin](../trackheightmixin#volatile-scrolltop) | | **loadedRegions**
loadedRegions: regionDataMap<LoadedRegion>('loadedRegions') | regions whose data has been fetched and committed, keyed by displayedRegionIndex; populated only after the fetch work callback returns | [MultiRegionDisplayMixin](../multiregiondisplaymixin#volatile-loadedregions) | | **forceLoadTrack**
forceLoadTrack: false | The force-load button's track-wide approval. Volatile so it never reaches a saved session; the `forceLoad` config slot is the durable form. | [RegionTooLargeMixin](../regiontoolargemixin#volatile-forceloadtrack) | | **byteEstimate**
byteEstimate: undefined as ByteEstimate | undefined | The last byte measurement: bytes, the span they were taken at, and whether zooming has been shown not to shrink them. Survives `clearAllRpcData`; dropped on chromosome navigation and on a tier swap. | [RegionTooLargeMixin](../regiontoolargemixin#volatile-byteestimate) | | **gateMeasuredViewportKey**
gateMeasuredViewportKey: undefined as string | undefined | The viewport key the gate last asked the adapter about, on either axis. Separate from `byteEstimate` because a density refusal measures no bytes. | [RegionTooLargeMixin](../regiontoolargemixin#volatile-gatemeasuredviewportkey) | | **canvasDrawn**
canvasDrawn: false | flips true on first paint; read by test selectors to detect render | [RenderLifecycleMixin](../renderlifecyclemixin#volatile-canvasdrawn) | | **currentRenderingBackend**
currentRenderingBackend: undefined | current backend reference, updated on context-loss recovery. Typed `unknown` (not generic `B`) on purpose: this mixin is composed by every display via a non-generic factory, so the per-display backend type `B` isn't known here — it's supplied at `attachRenderingBackend` and narrowed with `as B` inside the autoruns. Don't "fix" the cast. | [RenderLifecycleMixin](../renderlifecyclemixin#volatile-currentrenderingbackend) | | **renderTick**
renderTick: 0 | counter the render autorun observes; bumped to force a re-render | [RenderLifecycleMixin](../renderlifecyclemixin#volatile-rendertick) | | **autorunsInstalled**
autorunsInstalled: false | guards attachRenderingBackend so the autorun pair spawns once per instance | [RenderLifecycleMixin](../renderlifecyclemixin#volatile-autorunsinstalled) | | **renderError**
renderError: undefined | the render-backend (GPU/Canvas2D init or context-loss) error, or undefined. Single source of truth for the render-error terminal state: `useRenderingBackend` writes it from the canvas-init mechanism so the model — not React-local hook state — owns every terminal state. Read by `displayPhase` (whose `renderError` term outranks `loading`, suppressing the scrim) and by `DisplayChrome` (shows the retry overlay). | [RenderLifecycleMixin](../renderlifecyclemixin#volatile-rendererror) | | **activeStopToken**
activeStopToken: undefined as StopToken | undefined | stop token of the in-flight fetch, or undefined when idle | [FetchMixin](../fetchmixin#volatile-activestoptoken) | | **fetchGeneration**
fetchGeneration: 0 | bumps at every fetch end; autoruns read it to re-evaluate, and it doubles as the staleness epoch inside runFetch | [FetchMixin](../fetchmixin#volatile-fetchgeneration) | | **reloadCounter**
reloadCounter: 0 | Bumped by `reload()` and read unconditionally by the fetch autoruns, so a user retry re-runs the body even where nothing else moved — after an error every other fetch input is unchanged. It is also the half that survives a `reload()` override that forgets to invalidate, which is the dead Retry button `makeRetryContractCheck` reports. Declared here because this is the one mixin both LGV fetch foundations compose, the same argument that put `fetchInert` below; the comparative family carries its own on `SyntenyFetchStateMixin` (ADR-054). | [FetchMixin](../fetchmixin#volatile-reloadcounter) | | **statusWindow**
statusWindow: createStatusWindow(writeStatus(self)) | This display's status field, and the only thing that writes it: one throttle window, one slot per concurrent operation, so N parallel per-region fetches thin to one stream between them rather than N and a second operation cannot end the first one's label (ADR-081). Lent whole to `createStopTokenRotation` by a display that also runs a bare-autorun fetch — see `StatusReporter`. | [FetchMixin](../fetchmixin#volatile-statuswindow) | | **fetchCanceled**
fetchCanceled: false | true after the user explicitly cancels a load (the loading overlay's cancel button → `cancelFetchByUser`). A durable, blocking state — unlike `cancelFetch`, it does not retrigger the fetch autoruns — so the load stays stopped until the user retries (`reload`) or the viewport changes. Any new fetch clears it (`runFetch` resets it at the start). | [FetchMixin](../fetchmixin#volatile-fetchcanceled) | | **fetchRotation**
fetchRotation: createStopTokenRotation(self, { statusWindow: self.statusWindow, })
| **The latest-wins machine this mixin is a wrapper around**, and not a second one: `createStopTokenRotation` owns token rotation, the `isCurrent` guard, the status slot and the supersede-versus-end rule (ADR-080, ADR-081), for every fetch in the codebase that has one. `runFetch` adds the observable bookkeeping a display needs on top — `isLoading`, `error`, `fetchGeneration`, `fetchCanceled` — and nothing else.

It was two implementations of that machine until 2026-08-20, which is how they came to disagree about whether a completed fetch releases its token. A display's *primary* fetch is this wrapper; a second concurrent fetch on the same node holds a rotation of its own, which is why the primitive is the thing that exists and this is the thing built on it (ADR-054 §1).

It is lent this display's `statusWindow`, so the fetch takes a slot on the one field rather than opening a second window over it — the whole point of `StatusReporter`. | [FetchMixin](../fetchmixin#volatile-fetchrotation) | | **densityStatsPerRegion**
densityStatsPerRegion: regionDataMap<RegionDensityStats>( 'densityStatsPerRegion', )
| Per-region feature counts, keyed by `displayedRegionIndex`, so the verdict is a live max at the current `bpPerPx`. Cleared on navigation. | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#volatile-densitystatsperregion) | | **hoveredTreeNode**
hoveredTreeNode: undefined as HoveredTreeNode | undefined | | [TreeSidebarMixin](../treesidebarmixin#volatile-hoveredtreenode) | | **treeCanvas**
treeCanvas: null as HTMLCanvasElement | null | | [TreeSidebarMixin](../treesidebarmixin#volatile-treecanvas) | | **mouseoverCanvas**
mouseoverCanvas: null as HTMLCanvasElement | null | | [TreeSidebarMixin](../treesidebarmixin#volatile-mouseovercanvas) | | **contextMenuInfo**
contextMenuInfo: undefined as Info | undefined | | [ContextMenuMixin](../contextmenumixin#volatile-contextmenuinfo) | ## Getters | Member | Description | Defined by | | --- | --- | --- | | **view**
ModelInstanceTypeProps<_OverrideProps<_OverrideProps<…>, { ...; }>> & ... 25 more ... & IStateTreeNode<...>
| | LinearMultiRowFeatureDisplay | | **hoveredFeature**
MultiRowHit | undefined | Fills `BaseDisplay`'s cross-display hover hook, which the view reads to publish `session.hovered`. | LinearMultiRowFeatureDisplay | | **conf**
ModelInstanceTypeProps<Record<…>> & { setSubschema(slotName: string, data: Record<string, unknown>): any; setSlot(slotName: string, value: unknown): void; } & IStateTreeNode<...>
| config typed off the concrete schema (ConfigurationReference erases it to any); direct reads route through here to stay typed | LinearMultiRowFeatureDisplay | | **densityGateEnabled**
boolean | Multi-row paints features into fixed lanes, so a high total feature count (e.g. a whole-chromosome haplotype painting with many segments per row) is not a per-glyph render cost — only the byte/download budget should gate it. Disable the density axis of CanvasFeatureGateMixin so the "too many features" banner never shows here. | LinearMultiRowFeatureDisplay | | **showRowSeparators**
boolean | | LinearMultiRowFeatureDisplay | | **colorRowLabels**
boolean | Whether the sidebar label box is tinted with the color its row is painted in — see `labelSources`. | LinearMultiRowFeatureDisplay | | **partitionField**
string | The `partitionField` slot — an attribute name, or a `jexl:` expression — forwarded to the worker, which binds `feature` and resolves it per feature (`makeFeaturePartitionResolver`).

Reads the raw slot value, not `readConfObject`/`getConf`: this is a transport read, and the resolving readers evaluate a callback against whatever context the call passes, which here is none. The rmsk recipe this slot documents resolved that way to `''` — `feature.name` is `undefined` and `split` is total — and `''` shipped to the worker as an attribute name, so every feature answered `feature.get('')` and the track drew one unnamed row, with nothing thrown anywhere. Pinned end-to-end by partitionFieldTransport.test.ts. | LinearMultiRowFeatureDisplay | | **lengthField**
string | Feature attribute holding a signed bp length change vs the reference. Empty = the indel-glyph pass is off. A fetch input: it decides whether the worker packs `featureDeltas` at all. | LinearMultiRowFeatureDisplay | | **rowOrder**
string[] | Optional explicit row order from config; values listed here are placed first, remaining discovered values follow in sorted order. | LinearMultiRowFeatureDisplay | | **colorConfig**
string | undefined | Raw `color` slot (a CSS color or `jexl:` string, or undefined when unset), forwarded to the worker which resolves it per feature. | LinearMultiRowFeatureDisplay | | **sampleColorMap**
Record<string, string> | Map of partition value → color, forwarded to the worker which applies it over the per-feature `color`. | LinearMultiRowFeatureDisplay | | **rowProportion**
number | | LinearMultiRowFeatureDisplay | | **rowGroups**
RowGroup[] | Regex-to-group entries tagging rows with a sidebar swatch color. Applied in `sources`, downstream of `layout`, so the derived color never lands in persisted state — a `rowGroups` edit then takes effect on a session that already has a clustered layout, instead of losing to the stale copy. | LinearMultiRowFeatureDisplay | | **sourcesWithoutLayout**
MultiRowSource[] | Rows discovered in the loaded data: the distinct partition values across all loaded regions, ordered by the config `rowOrder` then sorted. The pre-layout, pre-filter input to the arrangement dialog and to clustering. | LinearMultiRowFeatureDisplay | | **usedItemRgb**
boolean | Whether the loaded data colored itself via `itemRgb` (only possible with the `color` slot at its default). Suppresses the per-row palette, which would otherwise paint over those colors. | LinearMultiRowFeatureDisplay | | **effectivePartitionField**
string | The attribute the rows are actually partitioned on: the `partitionField` slot, or — with the slot at its empty default — what the worker picked off the columns the data turned out to carry (`resolvePartitionField`, `repClass` on a RepeatMasker file). `name` until something has loaded, which is what auto falls back to anyway.

The resolved twin of the `partitionField` transport read above, which stays the raw slot because that is what the fetch has to send — resolve it there and the worker would be handed the main thread's guess at a question only the worker can answer, and the auto pick could never happen. Everything that asks "which attribute are these rows" — the menu's radio, the clustering call that has to land features in the rows the painting drew — reads this one.

Off the first loaded region rather than a vote across them: one file's columns are one file's columns, and a region that disagreed would be a different partition, not a tiebreak. | LinearMultiRowFeatureDisplay | | **partitionCandidates**
string[] | The attribute names the loaded features carry, which is what the "Partition by..." menu offers. Unioned across regions and re-sorted, since two regions can be served by adapters that saw different optional columns.

Empty until something is loaded, which is the menu's own disabled condition — the names are discovered from the data rather than declared, the same way the rows themselves are. | LinearMultiRowFeatureDisplay | | **editableSources**
MultiRowSource[] | Discovered rows with the user's arrangement (reorder/relabel) applied — what the arrangement dialog edits. Not subtree-filtered. | LinearMultiRowFeatureDisplay | | **sources**
MultiRowSource[] | The display rows: `editableSources` narrowed by the active subtree filter. Render order, label order, and `rowIndexByValue` all key off this, so reordering/filtering flows through to the painting.

`rowGroups` decorates them here, and **partitions them into blocks only when no cluster tree already names this order**. Grouping and ordering are two questions about one axis, and a config carrying both used to resolve them by having `rowGroups` win and the dendrogram vanish behind `StaleTreeHint` — a silent trade of the tree for a stripe. A clustered track is exactly where the stripe is worth most: it is the axis the clustering did NOT see, so reading it across the blocks the tree found is what says whether they correspond. | LinearMultiRowFeatureDisplay | | **rowIndexByValue**
Map<string, number> | | LinearMultiRowFeatureDisplay | | **rowColorStringsByIndex**
(string | undefined)[] | Per-row color (CSS) by display row — the single per-row resolver (dialog color > config `sampleColorMap` > palette-when-default). `undefined` where the row has none, and the worker-baked per-feature color paints instead. | LinearMultiRowFeatureDisplay | | **rowColorsByIndex**
(number | undefined)[] | `rowColorStringsByIndex` packed for the painters. Applied at render time over the worker-baked per-feature `color` slot, so any color change repaints without a refetch. | LinearMultiRowFeatureDisplay | | **labelSources**
MultiRowSource[] | The rows as the sidebar draws them: `sources`, with each row's painted color carried into `labelColor` when `colorRowLabels` is on.

Off by default because the tint is not free — it spends the label box, which `rowGroups` also spends (and wins here, along with a color set in the arrangement dialog: both are something the user or the config asked for by name, where this is derived). It earns the space on a painting whose rows are palette-colored and whose labels are a wall of similar names, and costs legibility on one where the labels were doing fine, which is why it is a toggle rather than a judgment made here.

A no-op in per-feature color mode: there is no single color a row is painted in, `rowColorStringsByIndex` is `undefined` throughout, and the labels come back exactly as `sources` had them. | LinearMultiRowFeatureDisplay | | **nrow**
number | Number of displayed rows (at least 1, so the auto-fit division is safe and the canvas mounts before data arrives). | LinearMultiRowFeatureDisplay | | **fitTargetHeight**
number | The track height that auto-fit mode divides among rows: the `height` config slot (its default, or a drag-resized value written to it). | LinearMultiRowFeatureDisplay | | **colorLegend**
LegendEntry[] | Categorical color key. The explicit `legend` config slot wins when set (for color-encoded categories with no feature attribute to key on, e.g. an itemRgb ancestry painting); otherwise it's auto-derived from the loaded data as distinct `(featureName -> per-feature color)` pairs among per-feature-colored rows. Empty in per-row palette / sampleColorMap mode (where the sidebar labels are the key) and for non-categorical (unnamed / all-distinct) data. See resolveConfiguredLegend / buildColorLegend. | LinearMultiRowFeatureDisplay | | **hiddenCategorySet**
ReadonlySet<string> | `hiddenCategories` as a Set, and the single place "is this category hidden?" is answered: the on-screen and SVG-export legends (dimmed rows), `hiddenColors`, and the track menu's category checkboxes all read it. One derivation rather than four, so a change to how a label is matched can't reach some of the legends and miss the rest. | LinearMultiRowFeatureDisplay | | **hiddenColors**
ReadonlySet<number> | ABGR colors currently hidden via the legend's category toggles: the `colorLegend` colors whose label is in `hiddenCategories`. Both render paths and the hit-test skip features painted in one of these, so toggling a category off drops it everywhere without a refetch. `colorLegend` has one entry per distinct color (see buildColorLegend), so each toggle maps to exactly one color. | LinearMultiRowFeatureDisplay | | **autoRowHeight**
number | The auto-fit row height: the display height split evenly across rows, so all rows stay visible as the row count grows.

Not floored at a pixel: a display given thousands of rows would otherwise stop fitting and grow to a pixel a row instead, which is a track thousands of pixels tall rather than the dense overview asked for. The floor lives in `rowBand`, where a sub-pixel row is widened for drawing without changing how many rows fit. | LinearMultiRowFeatureDisplay | | **maxCanvasHeight**
number | Ceiling on the whole row stack in CSS px, because this display sizes its canvas to its *content* and never scrolls: `height` is the canvas, so nothing downstream bounds it. What goes wrong past it, and why it is a function rather than a constant, is `maxCanvasCssPx`'s. A fixed 14px row height over a 1,987-row cohort — two clicks in the Row height menu — is 27,818 CSS px, well past it.

MAF meets the same limit with `maxRowsHeight`, but its canvas is a viewport it can scroll the overflow into. Here the cap has to land on the row height instead (below), so the rows thin out and every one of them stays on screen — which is what this display is for. | LinearMultiRowFeatureDisplay | | **effectiveRowHeight**
number | The one override of `RowHeightMixin`'s resolved height, and the reason is structural: this display sizes its canvas to its *content* instead of scrolling a viewport, so nothing downstream bounds the row stack and the cap has to land here. `maxCanvasHeight / nrow` is that cap; past it the rows thin out and every one of them stays on screen, which is what this display is for.

The sentinel resolution and the non-positive floor stay the mixin's `resolveRowHeight` — `featureAt` and `rowBand` divide by this, so a `height` slot configured to 0 must not reach them as a 0.

The cap is not floored back up afterwards: a row below a pixel is legitimate here (see `autoRowHeight`), and `rowBand` is where a sub-pixel row is widened for drawing without changing how many of them fit. | LinearMultiRowFeatureDisplay | | **rowGroupLegend**
LegendItem[] | Key for the `rowGroups` stripe: one row per (group, color) pair present, in first-appearance order, in the color the sidebar swatch is painted.

**Empty unless that stripe is the only thing carrying row identity.** Above `rowLabelsCarryText` the sidebar writes each row's name beside it and a key would restate them. Below it `RowLabelsOverlay` drops to an unlabelled swatch, and 1,987 canids at 0.32 px a row are then five group colors with nothing saying what any of them is — the same hole multi-wiggle's key closed, on the display whose figure the swatch stripe was built for.

A different vocabulary from `colorLegend`, which keys the per-feature painting and drives the category toggles; these rows name rows, and are not toggleable. `legendIsReadable` refuses the degenerate cases — one group, or more groups than a reader can scan.

`showRowLabels` gates it too, because that toggle takes the stripe with it rather than only the text: `RowLabelsOverlay` renders no `SvgRowLabels` at all when it is off, and `SvgRowLabels` is where the swatch runs are drawn. Without this the labels-off dense case published a "Row groups" key naming colors that appear nowhere on the plot — the exact inverse of the case above, from the same one-line question asked about only half of what draws the stripe. | LinearMultiRowFeatureDisplay | | **height**
number | Override BaseLinearDisplay.height so the track container matches the rendering canvas (numRows × effectiveRowHeight). In auto-fit mode this resolves to `fitTargetHeight`; in fixed mode it grows with the row count — this display grows to its content rather than scrolling a fixed viewport, which is why a fixed-mode drag re-pins the row height (see `setHeight`) instead of leaving it alone the way the scrolling row displays do.

Bounded by `maxCanvasHeight` through `effectiveRowHeight`, so growing to the content stops at the canvas limit rather than at nothing. A drag past it therefore returns 0 from `resizeHeight` and simply stalls. | LinearMultiRowFeatureDisplay | | **hierarchy**
ClusterHierarchyNode | undefined | Positioned dendrogram (when a cluster tree exists and describes the rows on screen). Leaves spaced over `height`, branches over `treeAreaWidth`.

Passes the *drawn* row names, which is the backstop for anything that reorders `sources` downstream of `layout` where `setLayout`'s invalidation cannot see it: such a reorder drops the dendrogram rather than drawing it against rows it does not name. `rowGroups` used to be the way to reach that state, and no longer is — it declines to partition while a tree describes the rows (see `sources`), so the two now compose instead of one silently costing the other. | LinearMultiRowFeatureDisplay | | **sidebarOffset**
number | Pixel width reserved on the left for the tree (0 when no tree shows). | LinearMultiRowFeatureDisplay | | **spatialIndex**
TreeSpatialIndex | undefined | | LinearMultiRowFeatureDisplay | | **featurePaintInputs**
Pick<MultiRowRenderState, "hiddenColors" | "rowColorsByIndex" | "rowIndexByValue">
| The three inputs to "does this feature paint, and in what color" — `featurePainting`'s whole contract, and nothing else.

Split out of `renderState` because the two have different lifetimes and the difference is expensive. `renderState` also carries the canvas box and the row geometry, all four of which move on a track-height drag or a window resize; this moves only on a reorder, a recolor, a category toggle or a refetch. The consumers that answer the paint question and nothing else — the per-region GPU encode autorun and the hit test's memoized contexts — read this, so a resize no longer re-encodes every region's instance buffer (a full pass over every feature, per drag frame) to arrive at byte-identical output. | LinearMultiRowFeatureDisplay | | **renderState**
MultiRowRenderState | Render state passed to the GPU/Canvas2D backend each frame. | LinearMultiRowFeatureDisplay | | **indelGlyphRegions**
Map<number, MultiRowRegionData> | undefined | Per-region data for the indel-glyph overlay, or undefined when the `lengthField` slot is unset and there is no glyph pass.

A computed returning a plain `Map` rather than `rpcDataMap` itself: the overlay draws inside an effect, so nothing it touches there is tracked, and handing it the ObservableMap would mean a refetch never redrew the glyphs. Rebuilding here makes the read happen where MobX sees it and gives the overlay a value whose identity changes exactly when the data does. | LinearMultiRowFeatureDisplay | | **drawnFeaturesByRow**
Map<number, DrawnFeaturesByRow> | Per-region drawn features bucketed by display row, keyed by displayedRegionIndex. Built through `forEachDrawnFeature` off the same `featurePaintInputs` the painters use, so the hit test cannot answer "is this feature drawn" differently from the paint that put it there.

Memoized because the hit test needs it per *pointer frame*: `featureAt` runs on every rAF-coalesced mouse move, and building it inline meant resolving the region's whole partition list (a couple of thousand rows on a cohort painting) sixty times a second for a value that changes only when the rows, the colors or the data do.

Bucketing rather than a bare context, because the memo only removed the *setup* from the pointer frame and left the scan: the row is known before the search starts, so a hit on a 200-feature row was still walking the region's other half-million. See `findTopDrawnFeatureInRow`.

`featurePaintInputs` rather than the whole `renderState`, so that "changes only when the rows, the colors or the data do" is actually true — see there. | LinearMultiRowFeatureDisplay | | **highlightedBlockRect**
{ left: number; width: number; top: number; height: number; } | undefined
| Screen box of the block to mark, or undefined when there's nothing to mark. The hover drops when a right-click menu opens (else its tooltip sticks under the menu), so the menu's own feature stands in — the block a menu is acting on is exactly the one that should stay marked. | LinearMultiRowFeatureDisplay | | **parentTrack**
AbstractTrackModel | | [BaseDisplay](../basedisplay#getter-parenttrack) | | **RenderingComponent**
FC<…> | | [BaseDisplay](../basedisplay#getter-renderingcomponent) | | **DisplayBlurb**
FC<{ model: ModelInstanceTypeProps<{ id: IOptionalIType<ISimpleType<string>, [undefined]>; type: ISimpleType<string>; }> & { ...; } & { ...; } & IStateTreeNode<...>; }> | null
| | [BaseDisplay](../basedisplay#getter-displayblurb) | | **adapterConfig**
Record<string, unknown> | | [BaseDisplay](../basedisplay#getter-adapterconfig) | | **isMinimized**
boolean | Returns true if the parent track is minimized. Used to skip expensive operations like autoruns when track is not visible. | [BaseDisplay](../basedisplay#getter-isminimized) | | **featureNoun**
string | Overridable hook (default `'feature'`): the SINGULAR word for one of the things this display draws, as a menu row or a chip says it — "Hide this read", "Showing 3 variants".

Declared here for the same reason as `hoveredFeature` above: it is read across the display boundary, by chrome that has no idea which display it is drawing for (`SoloSelectionChip`, alignments' group-label overlay), and a name only the base declares is a name every such consumer can rely on. Two displays declared it independently and one of those declarations WAS this default.

**A control keeps the generic word; content takes this one.** "Variant height" reads as a different setting from "Feature height" when it is the same one, so the shared menus stay on "feature" however the display answers here, and the noun varies where it names what the user is looking at — "Showing 3 variants", "Hide this read". A display drawing something the generic word already fits is right to leave this alone.

Distinct from the per-hit noun a context menu takes off the clicked item's own `type` ("mRNA", "gene"); that names one annotation, this names what the track holds. The hit noun falls back to this. | [BaseDisplay](../basedisplay#getter-featurenoun) | | **featureWidgetType**
{ type: string; id: string; } | Overridable hook: which widget `openFeatureWidget` opens for one of this display's features. The default is the generic one, which is what a display drawing plain features wants and what the canvas base spelled out by hand.

An override is a display whose features have a vocabulary of their own — a read, a variant, a synteny block — and the `id` is deliberately part of it: two displays naming one id share the drawer panel, which is the behaviour when the two are showing the same kind of thing. | [BaseDisplay](../basedisplay#getter-featurewidgettype) | | **resizing**
boolean | True for the duration of a height drag on this track, whichever handle is running it. A display whose row geometry is a function of the track height restretches every row per animation frame, and can use this to sit an expensive per-frame layer out of the drag (MAF's dense per-base letter overlay is a Canvas2D pass that scales with rows x columns).

The flag itself is the track's (`BaseTrackModel`), so the view brackets a drag without needing the active display to have opted into this mixin. Reading it here is what makes `self.resizing` available to a display that did. | [TrackHeightMixin](../trackheightmixin#getter-resizing) | | **scrollableHeight**
number | Overridable hook: how far this display's content can scroll past its viewport, in px. `Infinity` (the default) means "this display doesn't scroll internally" — `setScrollTop` then never clamps and the re-clamp autorun below is inert, so a non-scrolling display pays nothing and, crucially, never evaluates a getter that would read view geometry.

A display that scrolls a canvas overrides this with `max(0, contentHeight - viewportHeight)`, and gets the clamped setter plus the shrink autorun for free. It is the single "does it scroll, and by how much" answer: the wheel handler (`useVirtualScrollWheel`) and `VerticalScrollbar` read the same getter. | [TrackHeightMixin](../trackheightmixin#getter-scrollableheight) | | **host**
RegionHost | The containing LinearGenomeView, typed once for every display in this family — see `containingHost` for the cast it owns and why both foundations still declare the name. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-host) | | **canvasWidthPx**
number | The CSS width of this display's on-screen canvas, in px — and the `canvasWidth` its `renderState` must carry, since the two have to agree or the bp→px mapping is scaled against a box it doesn't fill.

`trackWidthPx`, **not** `view.width`: `TrackRenderingContainer` insets the rendering component by the 2px track outline under `contain: strict`, so a `view.width`-wide canvas overhangs its own container and the browser clips the overhang away. It renders almost identically, which is why MAF drifted onto `view.width` uncaught.

A getter rather than a note on each display, because the choice was being made by copying a neighbour out of four plausible view getters — `width` (the viewport), this one, and `totalWidthPx` / `totalWidthPxWithoutBorders` (the *content* width, which the global family's heatmaps legitimately want: a different question, not a different answer). `no-restricted-syntax` bans the underlying read everywhere but this line, since a second spelling agrees until it doesn't.

SVG export is the one exception: the export shell has no outline, so `renderSvg` overrides `canvasWidth` with the shell's own width (see `LgvSvgBodyProps`). | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-canvaswidthpx) | | **canRender**
boolean | Overrides `RenderLifecycleMixin`'s default-true hook with the LGV precondition both foundations share — see `foundationCanRender`. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-canrender) | | **viewportWithinLoadedData**
boolean | true when every visible block lies within an already-fetched region — i.e. the viewport shows data we actually loaded, not the stale fringe left after a zoom-out/pan. Drives the loading overlay through the pre-refetch debounce.

**Spatial only, and it stays that way.** Whether the data held for a block is still what a fetch would bring back is `isCacheValid`, which `dataCurrent` conjoins for the export gate. The scrim reads this getter alone: a phase that went `loading` on a moved `regionFetchKey` would raise the overlay into every zoom. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-viewportwithinloadeddata) | | **viewportEmpty**
boolean | No content block is on screen, so this display has nothing to fetch and nothing to paint — see `viewportEmpty.ts` for the one viewport that reaches it, how narrow that is, and why the state still has to be terminal rather than a permanent scrim. Both foundations declare it over that one expression, the same way they each declare `host` and `paintInert`. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-viewportempty) | | **layoutReady**
boolean | Overridable hook (default false): whether a searchable feature layout currently exists. Any display defining a feature-lookup method (`searchFeatureByID`, `getFeatureById`) must override it, so callers can tell "laid out, but off-display" from "no layout exists yet" — a distinction only the display can make. See packages/display-kit/CLAUDE.md §"Four readiness axes". | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-layoutready) | | **regionFetchKey**
string | Overridable hook (default `''`): what a fetch issued right now would produce for a region, as a string — the display's per-region content axis. `fetchRegions` captures it before it issues the RPC and stamps it beside the loaded region; `isCacheValid` refetches a region whose stamp no longer matches. Wiggle returns `String(view.bpPerPx)` (adr-008), canvas the peptide-overlay threshold, the variant matrix its zoom in matrix mode only.

NOT an `rpcProps()` field: this invalidates one region's held data where `rpcProps` invalidates all of it, and a zoom-swinging value in the RPC payload blanks the display at the force-load floor — see REGION_TOO_LARGE.md §"How the verdict is built".

A getter, so the observables it reads register as dependencies of `FetchVisibleRegions`; MobX runs an action untracked and the autorun would keep a stale answer. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-regionfetchkey) | | **dataSuperseded**
boolean | Overridable hook (default false): the held data is loaded and covers the viewport, but a fetch input has moved past it, so the data is about to be cleared and refetched. A display says so here rather than overriding `dataCurrent`, for the reason `FetchMixin.fetchInert` is a hook: an override has to restate the freshness terms and then misses the next one added.

On screen this window is invisible (the clear lands a tick later and the loading scrim covers it), which is exactly why it needs saying: `awaitSvgReady` samples freshness once, and an export that samples it inside this window renders the data that is about to be discarded — or, once the clear lands mid-render, nothing at all. GWAS's LD auto-index is the case: adopting the top hit as the index SNP is an `rpcProps` change, so the very load that produced the top hit is what it invalidates.

**The input need not have settled yet.** Alignments counts the debounce window ahead of its per-base bin, where the bin the data was fetched under has not moved and the clear is inevitable rather than committed. That is the half of the window an export lands in, since a reader zooms and then reaches for the menu. What may NOT go in is a change that could still be taken back: this fails hung, not stale.

So state the live-vs-settled half as a **value** compare and leave key strings alone. The settled half — the stamp a fetch committed under against the key a fetch now would use — is the foundation's already, through the `isCacheValid` term in `dataCurrent`, and an override restating it buys nothing: a second derivation of the key's vocabulary reads `"16\|fine"` against a live `"16"` the day the key grows an axis, latches this true, and every export of the display then waits out `awaitSvgReady`'s backstop instead of failing. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-datasuperseded) | | **renderBlocks**
RenderBlock[] | Shared cached view for every LGV-based GPU display. A single displayedRegion may produce multiple render blocks (shared GPU buffer, different scissor clips on screen). Plugins that want to suppress rendering in certain states (e.g. no domain yet) can override this getter to return [] — the autorun lifecycle will then issue an empty-blocks render that clears the canvas. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-renderblocks) | | **dataCurrent**
boolean | This family's answer to the shared freshness question every display foundation must answer (`dataCurrent`): the held data corresponds to what is on screen right now. Four terms — spatial coverage of every visible block, `loadedRegions.size` to rule out the vacuously-true empty viewport, `isCacheValid` per block, and the display's own `dataSuperseded`. Regions stream in one at a time, so this (not "the first datum arrived") is what keeps a multi-region/whole-genome export complete.

**`isCacheValid` belongs here and not in the scrim.** Coverage answers "is the data here", never "is it what a fetch now would bring back", so a zoom that moves `regionFetchKey` leaves every held region covered and stale at once — and an export sampling `svgReady` across that window painted bins the worker computed for the previous zoom. `displayPhase` still reads `viewportWithinLoadedData` alone: folding staleness into the phase raises the loading scrim into every zoom, which is the trade REJECTED_IDEAS.md "Folding content staleness into `displayPhase`" turned down and this does not take.

The term cannot latch, and the reason is structural rather than a case list: a block reaches `fetchNeeded` unless `planRegionFetch` finds it ungated, covered AND cache-valid, and it reads that last term tracked. The `&&` short-circuits ahead of it drop its observables only where the block is fetched anyway, so the key move that closes this gate is the same read, in the same dependency set, that wakes the refetch reopening it. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-datacurrent) | | **loadedAssembly**
(ModelInstanceTypeProps<…> & { error: unknown; loadingP: Promise<…> | undefined; ... 10 more ...; refNameMismatches: Map<…>; } & ... 13 more ... & IStateTreeNode<...>) | undefined
| The assembly the data in hand came from, once it can answer about refNames — `undefined` before that.

Off the first LOADED region rather than the view's displayed ones, which is the distinction that makes it belong here: a display holding fetched data is asking about the assembly THAT data is on, and the view's regions can already have moved on.

The `initialized` gate is why this returns the assembly rather than its name. `getCanonicalRefName2` and `refNameToIndex` answer WRONGLY rather than throwing before the aliases land — identity, and a miss — so a caller that skips the gate gets a plausible answer and no signal. Handing back `undefined` until it can answer is what makes the caller write its fallback. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-loadedassembly) | | **svgReady**
boolean | true once an off-screen (SVG) export can safely read this display's data. Policy single-sourced in `computeSvgReady`; this family supplies only the freshness half, which `foundationSvgReady` reads as `dataCurrent` or the vacuous currency of `viewportEmpty`. Off-screen renderers gate on it via `awaitSvgReady(model)` instead of inlining the condition. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-svgready) | | **paintInert**
boolean | Fills `RenderLifecycleMixin`'s `paintInert` hook — see there for why a failed fetch has to read as finished to the consumers outside the display, and `foundationPaintInert` for the second such state and why both fetch families answer it through one function. Overridable, as the hook is: a display with a third inert state of its own says so here. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-paintinert) | | **displayPhase**
DisplayPhase | The display's mutually-exclusive visual state, mapped in `foundationDisplayPhase` — every foundation calls it and supplies only its staleness argument, so a term added to `computeLoadingTerm` reaches all three without being wired three times.

This family's argument is spatial: `loading` also covers stale data (viewport past loaded) still on screen through the pre-refetch debounce. A thunk, so a suppressed or already-loading display doesn't subscribe to viewport churn.

A subclass customizes this through `fetchInert` (FetchMixin), never by overriding the getter — see that hook. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#getter-displayphase) | | **gateEnabled**
boolean | The opt-in. Overridden with a literal `true` by gated displays, and `check-gated-adapter-budgets` insists on a literal: this mixin returns early on it in an autorun and in `commitFetchBytes`. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gateenabled) | | **byteGateAdapterConfig**
Record<string, unknown> | The adapter config the gate measures — the one at `byteGateAdapterPath`. Overridable for a display whose adapter config is synthesized rather than read off the track. | [RegionTooLargeMixin](../regiontoolargemixin#getter-bytegateadapterconfig) | | **configuredFetchSizeLimit**
number | The display's `fetchSizeLimit` slot, from `regionTooLargeConfigSchemaFields`. | [RegionTooLargeMixin](../regiontoolargemixin#getter-configuredfetchsizelimit) | | **densityTooLarge**
boolean | The density axis's verdict; canvas overrides it. | [RegionTooLargeMixin](../regiontoolargemixin#getter-densitytoolarge) | | **byteGateAdapterPath**
string[] | Where on the track config the measured adapter sits. A tiered display overrides this one hook (MAF: `['adapter', 'summaryAdapter']` while `showSummary`), and both the measurement and the budget follow it. | [RegionTooLargeMixin](../regiontoolargemixin#getter-bytegateadapterpath) | | **adapterFetchSizeLimit**
number | undefined | The measured adapter's own `fetchSizeLimit` slot, read off the live track config rather than the `adapterConfig` snapshot, which omits slots at their default. | [RegionTooLargeMixin](../regiontoolargemixin#getter-adapterfetchsizelimit) | | **configForceLoad**
boolean | The declarative `forceLoad` slot. | [RegionTooLargeMixin](../regiontoolargemixin#getter-configforceload) | | **gateViewport**
GateViewport | undefined | What a measurement taken now would be about: the span on screen and a key for the stretch of genome it covers. Undefined until the view is measured, and the mixin's only read of the view. Captured before the fetch's round trip, never at commit. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gateviewport) | | **byteGateAdapterKey**
string | Which tier the estimate is about, as a comparable string. | [RegionTooLargeMixin](../regiontoolargemixin#getter-bytegateadapterkey) | | **aboveForceLoadFloor**
boolean | Whether the span on screen is at or above `AUTO_FORCE_LOAD_BP`, the one comparison against that constant. False on an unmeasured view. | [RegionTooLargeMixin](../regiontoolargemixin#getter-aboveforceloadfloor) | | **gateExempt**
boolean | Nothing may gate on either axis: the `forceLoad` slot or the button. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gateexempt) | | **estimatedFetchBytes**
number | undefined | The stored estimate's bytes; undefined when nothing has been measured. | [RegionTooLargeMixin](../regiontoolargemixin#getter-estimatedfetchbytes) | | **gateMeasurementStale**
boolean | Whether the last measurement is about a viewport the user has since left. True before any measurement. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gatemeasurementstale) | | **gateByteLimit**
number | The byte budget: the adapter's limit, else the display's, doubled below `AUTO_FORCE_LOAD_BP`. Read only through `resolvedByteLimit()`. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gatebytelimit) | | **gateActive**
boolean | Whether the gate may act right now, on any axis: opted in, not exempt, view measured. The view is read last, so an ungated display never touches it. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gateactive) | | **densityGateActive**
boolean | `gateActive` plus the density axis's own terms: the axis is on, and the span is above the floor. | [RegionTooLargeMixin](../regiontoolargemixin#getter-densitygateactive) | | **tooLargeStatus**
RegionTooLargeStatus | The verdict and its banner text, from the stored estimate against `resolvedByteLimit()` and the density axis when it may act. | [RegionTooLargeMixin](../regiontoolargemixin#getter-toolargestatus) | | **regionTooLarge**
boolean | | [RegionTooLargeMixin](../regiontoolargemixin#getter-regiontoolarge) | | **regionTooLargeReason**
string | Banner text for the axis that tripped; empty when not too large. | [RegionTooLargeMixin](../regiontoolargemixin#getter-regiontoolargereason) | | **zoomCanReleaseGate**
boolean | Whether "zoom in to see features" is honest advice. Density always releases on zoom; bytes only if the last zoom-in moved the estimate. | [RegionTooLargeMixin](../regiontoolargemixin#getter-zoomcanreleasegate) | | **gateSkipsMeasuredViewport**
boolean | The skip both fetch skeletons apply: the banner is up and its measurement already describes the viewport on screen. | [RegionTooLargeMixin](../regiontoolargemixin#getter-gateskipsmeasuredviewport) | | **rendersCanvas**
boolean | Overridable hook (default true): whether this display paints a canvas in its **current** configuration, as opposed to a deliberate static placeholder (LD with the triangle off, sequence past base resolution — both render a message where the ` | [RenderLifecycleMixin](../renderlifecyclemixin#getter-renderscanvas) | | **painted**
boolean | **The first-paint answer every consumer outside the display should read**, `canvasDrawn` being only the raw flag: a display that is deliberately not painting a canvas has finished, and saying otherwise is a lie that never resolves.

The two `rendersCanvas: false` states each had three of their four consumers wired by hand — the loading scrim (`rendersCanvas` / `fetchInert`) and the SVG export (`fetchInert`) — while the fourth, `data-display-drawn`, went on publishing `"false"` forever off the raw flag. That attribute is what `PENDING_DISPLAYS` (`@jbrowse/browser-test-utils`) selects on, so a zoomed-out reference sequence track made every `waitForDisplaysDone` on the page burn its full timeout — silently, since that wait swallows its own. Same shape as `fetchInert` on the comparative side: the reader you forget is the one outside the display, so the display has to publish one name for it.

`paintInert` is the third term and the same argument once more, for the state where a display *would* paint a canvas and never gets to — a fetch that failed before first paint. See that hook. | [RenderLifecycleMixin](../renderlifecyclemixin#getter-painted) | | **isLoading**
boolean | true while a fetch is active | [FetchMixin](../fetchmixin#getter-isloading) | | **isLoadingOrCanceled**
boolean | `isLoading` widened to cover a user-canceled load. **This, not `isLoading`, is what a `displayPhase` loading term wants.** `cancelFetchByUser` clears the stop token synchronously, so `isLoading` goes false the instant the user clicks Cancel — and the loading overlay that unmounts on it is carrying the Retry button, which is the only way back: the state is deliberately durable, so no autorun restarts the fetch on its own. A bare `isLoading` therefore reads as `ready` over a display that is stopped, empty and offering nothing.

Arc read `isLoading` directly and had exactly that hole. It is a getter here so no family has to remember the second term. | [FetchMixin](../fetchmixin#getter-isloadingorcanceled) | | **fetchInert**
boolean | Overridable hook (default false): the states where this display deliberately never fetches, so it holds no data and none is coming. Sequence sets it past base resolution ("Zoom in to see sequence"); LD sets it with the triangle toggled off.

**One hook, three readers**, and that is the whole point — a display that grows such a state has one thing to say rather than three, and the reader it would have forgotten is always the one outside itself:

- the loading scrim (`computeLoadingTerm`), which otherwise parks over the placeholder, permanently once a cancel has been clicked; - the SVG export (`computeSvgReady`'s `extraTerminal`), whose `awaitSvgReady` is an unbounded `when`, so one such display hangs the whole view's export; - the dev-only retry check (`makeRetryContractCheck`), which would otherwise report a dead Retry on a display correctly declining to load anything.

It was three hooks — `loadingSuppressed`, `svgReadyExtraTerminal` on each of the two foundations, and `fetchInert` on the comparative family, which had already collapsed them. Both LGV displays that override it returned one expression for all three, and one of the three was hard-coded `false` on the global family for a while, which is how LD came to be able to express only half its own state. Same name and same meaning as `SyntenyFetchStateMixin.fetchInert` now, so the retry check reads one field across all three fetch families. ADR-082.

A hook rather than a `displayPhase` override, because overriding the getter means restating the whole loading condition — which is how sequence came to hold a verbatim copy of the other terms, one `git blame` away from silently missing the next one added.

It lives **here** because this is the one mixin all three display foundations compose. Same argument, one level down, that put `rendersCanvas` on `RenderLifecycleMixin` beside `canvasDrawn`. | [FetchMixin](../fetchmixin#getter-fetchinert) | | **awaitingPrerequisite**
boolean | Overridable hook (default false), read only by the dev-only retry check (`makeRetryContractCheck`): "this run declined because a prerequisite fetch in another autorun has not landed, and its arrival wakes this one again". It **defers** the retry verdict to that later run rather than waiving it, so a display cannot spend its retry on a decline it called preliminary.

Two displays say it, one per fetch foundation, which is why it lives beside `fetchInert` rather than on either: HiC's contacts fetch declines until `CoreGetInfo` lands, and `MultiSampleVariantBaseModel`'s `fetchNeeded` declines until `sourcesBase` does. Both have a `reload()` that wakes the prerequisite's autorun as well as their own.

**It has to be strictly narrower than the gate it explains.** One that restates the gate's negation makes every decline a deferred one, so no run is ever judged and the display has silently opted out — an exemption by another name. HiC is in that shape deliberately, because its gate and its prerequisite are one condition; what covers its retry instead is `LinearHicDisplay/infoFetchFailure.test.ts`.

Not for a display deliberately not fetching at all — that is `fetchInert` above, which the loading scrim and the export read too. | [FetchMixin](../fetchmixin#getter-awaitingprerequisite) | | **rpcPropsCacheKey**
string | The RPC cache key both fetch foundations invalidate on: this display's `rpcProps()` payload serialized to a string. `serializeRpcProps` owns the why, including the silently-dead-axis corollary.

Here, beside the two hooks above, for the same reason they are: it describes the display, and every foundation composes this mixin. The per-region family watches it from `SettingsInvalidate` and the global one from its fetch autorun's trigger list — one getter and one name, so the two cannot come to invalidate on different axes. The global side built its own local `computed` over the same function until 2026-08, which was the same value under a second spelling. | [FetchMixin](../fetchmixin#getter-rpcpropscachekey) | | **visibleFeatureDensityPerPx**
number | Density at the debounced `coarseBpPerPx`, so the verdict shares the layout cadence. Zero before the view is measured. | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#getter-visiblefeaturedensityperpx) | | **maxFeatureDensity**
number | undefined | The worker's density budget; undefined when the axis may not act. | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#getter-maxfeaturedensity) | | **showLegend**
boolean | Whether the legend is drawn. Resolved through the promotable-slot tiers (`resolveConf`): an explicit track value customizes it either way, otherwise it follows the session-wide default for this display type, falling back to the slot's `promotedBase`. | [LegendMixin](../legendmixin#getter-showlegend) | | **showLegendDisplayTypeDefault**
Pin | The "make the current legend visibility the default for all tracks" control. Symmetric, so it promotes whichever value the track currently shows. `showLegendCheckboxItem` takes this as its `pin`. | [LegendMixin](../legendmixin#getter-showlegenddisplaytypedefault) | | **rowHeight**
number | Raw per-row height setting: `0` is fit-to-display-height, any positive value is a fixed px height. The resolved value is `effectiveRowHeight` — consumers read that, never this. On the config rather than the display snapshot for the same reason `height` is: the config node outlives the display instance, so a fixed height survives unticking and reticking the track. | [RowHeightMixin](../rowheightmixin#getter-rowheight) | | **showTree**
boolean | Whether the dendrogram sidebar is drawn. | [TreeSidebarMixin](../treesidebarmixin#getter-showtree) | | **showBranchLength**
boolean | Whether tree nodes are positioned by branch length (dendrogram) or evenly by topology (cladogram). | [TreeSidebarMixin](../treesidebarmixin#getter-showbranchlength) | | **showRowLabels**
boolean | Whether each row's name is drawn over the left of the plot. | [TreeSidebarMixin](../treesidebarmixin#getter-showrowlabels) | | **parsedTree**
HierarchyNode<NewickNode> | undefined | | [TreeSidebarMixin](../treesidebarmixin#getter-parsedtree) | | **root**
HierarchyNode<NewickNode> | undefined | | [TreeSidebarMixin](../treesidebarmixin#getter-root) | | **treeHasBranchLengths**
boolean | | [TreeSidebarMixin](../treesidebarmixin#getter-treehasbranchlengths) | | **rowOrderIsCustom**
boolean | Whether the rows have been arranged away from the order they arrived in — what "Reset row order" is offered on. A written `layout` here; a display whose config seeds `layout` on load (the multi-sample variant displays' `colorBy` / `groupBy`) overrides it to compare against that seed, so the reset does not appear on a track nobody has touched. | [TreeSidebarMixin](../treesidebarmixin#getter-roworderiscustom) | ## Methods | Member | Description | Defined by | | --- | --- | --- | | **rpcProps**
() => { partitionField: string; lengthField: string; colorConfig: string | undefined; }
| Fetch-input cache keys (tier-1, via SettingsInvalidate → refetch). Color is resolved in the worker, so the raw color slot is a key. | LinearMultiRowFeatureDisplay | | **featureAt**
(mouseX: number, mouseY: number) => MultiRowHit | undefined | Hit-test the feature under a display-relative pixel: row from `mouseY / rowHeight`, genomic bp from the view, then the first feature on that row whose `[start,end)` covers the bp. Returns undefined over the sidebar, off-row, out-of-bounds, or over a gap.

The sidebar bound is `treeSidebarRightEdge`, not `sidebarOffset`: the latter is where labels are *drawn* from, while the resize handle sitting in the 4px past it is the sidebar's interactive edge, and a hit under the handle would fight the drag. Same bound the wiggle family hit-tests against, and the same one the crosshair's guide stops at. | LinearMultiRowFeatureDisplay | | **contextTargetAt**
(mouseX: number, mouseY: number) => { refName: string; pos: number; hit: MultiRowHit | undefined; } | undefined
| What a right-click at this display-relative pixel resolves to: the genomic position the menu's position-scoped rows act on ("Sort rows by color here"), and the feature there when the click landed on one.

Undefined wherever no menu should open, which is what the component needs in order to decide whether to `preventDefault` — over the tree sidebar, which overlays this display and owns its own menu, and in the inter-region gutter, where there is no base to name. Model-side and beside `featureAt` because it is the same question about the same pixel; spelled out in the component it re-derived `pxToBp`, the sidebar bound and the painted base that `featureAt` was about to derive again. | LinearMultiRowFeatureDisplay | | **regionHasData**
(displayedRegionIndex: number) => boolean | The reader-side check of the write-side rule: `loadedRegions` is written where the payload is stored (`RegionFetchContext`), so an entry here without one in `rpcDataMap` is that rule being broken. It costs a map lookup and it decides which way the break fails — a refetch, or a viewport that reads as covered against data nobody has and never asks again.

No zoom rule beside it: the worker's output is absolute genomic uint32, so `regionFetchKey` stays at its empty default.

A view, not an action: as an action MobX untracks the `rpcDataMap` read and `FetchVisibleRegions` keeps a stale answer. | LinearMultiRowFeatureDisplay | | **contextMenuItems**
() => MenuItem[] | Items for the right-click context menu, built from the clicked position (contextMenuInfo). "Sort rows by color here" is the interactive twin of the declarative `sortRowsBy`. | LinearMultiRowFeatureDisplay | | **trackMenuItems**
() => MenuItem[] | | LinearMultiRowFeatureDisplay | | **renderingProps**
() => { displayModel: ModelInstanceTypeProps<{ id: IOptionalIType<…>; type: ISimpleType<string>; }> & { ...; } & { ...; } & { ...; } & IStateTreeNode<...>; }
| props passed to the renderer's React "Rendering" component. these are client-side only and never sent to the worker. includes displayModel and callbacks | [BaseDisplay](../basedisplay#method-renderingprops) | | **isCacheValid**
(displayedRegionIndex: number) => boolean | Whether the data held for a region still answers the current view. Not a hook a display fills: a display states its rule as `regionFetchKey` (what a fetch now would produce) and `regionHasData` (did the last one store anything), and this compares the key against the one the region was fetched under. A subclass that changes what it fetches spells the change in the key, and one that forgets gets a redundant fetch rather than a cached answer for a zoom the data was never fetched at. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#method-iscachevalid) | | **resolvedByteLimit**
() => number | undefined | The budget the worker enforces and the banner compares against — the one spelling of that pair. Undefined when the gate may not act. | [RegionTooLargeMixin](../regiontoolargemixin#method-resolvedbytelimit) | | **gateFetchState**
() => GateFetchState | The gate as it stands for a fetch about to be issued. Calling it is the capture, which is why it is a method. | [RegionTooLargeMixin](../regiontoolargemixin#method-gatefetchstate) | | **observedMaxDensity**
(bpPerPx: number) => number | Highest features-per-pixel across the visible regions at `bpPerPx`. | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#method-observedmaxdensity) | | **willClearTree**
(next: S[]) => boolean | | [TreeSidebarMixin](../treesidebarmixin#method-willcleartree) | ## Actions | Member | Description | Defined by | | --- | --- | --- | | **setShowRowSeparators**
(f: boolean) => void | | LinearMultiRowFeatureDisplay | | **setColorRowLabels**
(f: boolean) => void | | LinearMultiRowFeatureDisplay | | **toggleCategory**
(label: string) => void | Show/hide a legend category by label (render-time, no refetch). | LinearMultiRowFeatureDisplay | | **setHiddenCategories**
(labels: string[]) => void | | LinearMultiRowFeatureDisplay | | **setPartitionField**
(field: string) => void | Repartition: which feature attribute assigns a feature to a row.

A fetch input, so writing the slot refetches on its own — nothing here has to ask for one. What it DOES have to do is drop the state keyed on the old rows: `layout` names rows by value, so under a new partition its entries name rows that no longer exist, and `getSources` appends a row a layout omits rather than dropping it — the old row set would have come back beside the new one, empty, with a saved color each. Same for the hidden categories, whose labels are the old values.

`clearLayout`, not `setLayout([])`, because the subtree filter is keyed on row names too. It is otherwise independent of the tree and of the order — `filterRowsBySubtree` matches on `name` and needs neither, so `setLayout` deliberately keeps a focused clade across a reorder — but this is the one action here that renames the rows out from under it. Left set, it matched nothing and `sources` came back empty: a blank canvas with no row labels, recoverable only by finding "Clear subtree filter" in the track menu. `setPhasedMode` is the same action on the multi-sample variant displays and clears it for the same reason. | LinearMultiRowFeatureDisplay | | **sortRowsByValueAt**
(refName: string, pos: number) => void | Reorder the rows by the value each carries at (refName, pos) — the feature covering that position on each row. Reads the already-loaded region data (no refetch/RPC) and writes the new order via `layout`.

Declines with fewer than two rows to order, because the empty result is not a harmless no-op: `setLayout` clears the cluster tree whenever the row set changes, so writing it discards both the saved arrangement and the dendrogram a clustering run produced. The rows are DISCOVERED from `rpcDataMap` (see `sourcesWithoutLayout`), which empties whenever the display is panned off its data or blanked by the density gate — so "sorting" a track that is merely not loaded right now used to wipe it. `sortRowsBy`, the declarative twin, meets the same condition by waiting for the region instead (see setupRowSortAutorun); a click has nothing to wait for, so it declines.

Declines again when no loaded region covers the column, which is the gate `setupRowSortAutorun` and multi-wiggle's twin already applied and this did not: it filtered the regions by refName alone, so a position past the end of the loaded window gave every row "no value" and wrote back the order it already had. `loadedRegionIndexAt` is the one predicate all three now ask, and resolving to a single region is also what stops two loaded windows on one contig from both answering. | LinearMultiRowFeatureDisplay | | **setHoveredFeature**
(arg?: MultiRowHit | undefined) => void | Writes only when the hovered block actually changes, so a mouse moving within one block (blocks are many px wide) doesn't invalidate the observers watching this. | LinearMultiRowFeatureDisplay | | **selectFeatureById**
(featureId: string, displayedRegionIndex: number) => void | Re-fetch the full clicked feature by id and open it in the feature details widget. The painting ships only the slim render arrays, so the complete feature is fetched on demand (GetCanvasFeatureDetails). | LinearMultiRowFeatureDisplay | | **setRpcData**
(regionIndex: number, data: MultiRowRegionData) => void | | LinearMultiRowFeatureDisplay | | **clearDisplaySpecificData**
() => void | | LinearMultiRowFeatureDisplay | | **setHeight**
(newHeight: number) => number | Set the track height. In auto-fit mode the rows restretch to it; in fixed mode it's distributed across the current rows as a fixed row height. | LinearMultiRowFeatureDisplay | | **resizeHeight**
(distance: number) => number | Drag-resize. Defers to `setHeight`, which restretches rows in auto-fit mode and re-pins the row height in fixed mode. | LinearMultiRowFeatureDisplay | | **setFitToHeight**
() => void | Switch to auto-fit: seed the `height` config slot from the current content height (so toggling on doesn't jump), then `rowHeight = 0` makes `effectiveRowHeight` derive from it. | LinearMultiRowFeatureDisplay | | **startRenderingBackend**
(backend: MultiRowRenderingBackend) => void | | LinearMultiRowFeatureDisplay | | **fetchNeeded**
(needed: { region: Region; displayedRegionIndex: number; }[]) => Promise<void>
| | LinearMultiRowFeatureDisplay | | **renderSvg**
(opts: ExportSvgDisplayOptions) => Promise<ReactNode> | | LinearMultiRowFeatureDisplay | | **clearHoveredFeature**
() => void | Fills `BaseDisplay`'s hover-clear hook, which the fetch foundation's reaction calls on every viewport change.

The painting is a sticky canvas, so a pan or zoom fires no mousemove and no mouseleave and `hoveredFeature` keeps naming whatever used to be under the cursor. | LinearMultiRowFeatureDisplay | | **setStatusMessage**
(status?: RpcStatus | undefined) => void | | [BaseDisplay](../basedisplay#action-setstatusmessage) | | **setError**
(error?: unknown) => void | | [BaseDisplay](../basedisplay#action-seterror) | | **reload**
() => void | base display reload does nothing, see specialized displays for details | [BaseDisplay](../basedisplay#action-reload) | | **setScrollTop**
(scrollTop: number) => void | Clamped into `[0, scrollableHeight]`, so no caller has to remember the bound. Unbounded for a display that leaves `scrollableHeight` at its `Infinity` default. | [TrackHeightMixin](../trackheightmixin#action-setscrolltop) | | **expandToContentHeight**
() => number | Grow the track by exactly the content it is currently hiding, so a display scrolled over a taller stack ends up showing all of it. The track's resize handle runs this on a double click.

`scrollableHeight` is the whole measurement — it is already every scrolling display's answer to "how much is off the bottom", so no display has to supply a second one. A display that doesn't scroll internally leaves it at `Infinity` and gets a no-op, as does one already showing everything (0).

Routed through `resizeHeight` rather than `setHeight` so grow mode's override still gets to leave grow first; going straight to the slot would let the reactive height re-derive `grownHeight` and the double click would appear to do nothing. | [TrackHeightMixin](../trackheightmixin#action-expandtocontentheight) | | **setLoadedRegion**
(displayedRegionIndex: number, region: Region, fetchKey?: string) => void
| The raw write behind `ctx.commitRegion`, and **not what a fetch should call**: a display naming its own span is the bug this family spent a release on, and going through the context is what makes that inexpressible — see RegionFetchContext. Direct callers are tests staging an already-loaded display.

An action so callers after an async boundary stay in MST strict mode. Stamps the region with the fetch key its data came back under. `fetchRegions` passes the key it captured before issuing the RPC; the default reads it *now*, which is right for a caller holding the region already and wrong for anything resuming after an await, where the viewport may have moved under the fetch. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#action-setloadedregion) | | **dropLoadedRegion**
(displayedRegionIndex: number) => void | Forget one region — for a display pruning what has scrolled off screen. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#action-droploadedregion) | | **clearAllRpcData**
() => void | full reset: cancels fetch, clears error, loadedRegions, display-specific data, and the canvas-drawn flag. The too-large gate is derived (a pure function of the cached estimate × viewport), so it needs no explicit clear here — the fetch autorun re-measures at the new viewport and the verdict follows. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#action-clearallrpcdata) | | **fetchRegions**
(needed: IndexedRegion[], work: (ctx: RegionFetchContext) => Promise<void>) => Promise<void>
| Run a per-region fetch. The work callback calls `ctx.commitRegion` as it stores each region's payload, which is what marks it loaded — see RegionFetchContext for why this function no longer does that itself. Its only callers are the three helpers in `fetchEachRegion.ts`, which make that call for every display in the family; a display reaching past them owns both `ctx.isStale()` guards and the commit by hand, and none does.

The fetch key is captured here, at issue, and carried into every commit — never re-read after the await. `ctx.isStale()` trips on a newer fetch or a cancel, not on a viewport that moved under a fetch that is still current, so a key read at commit time would stamp this data with a zoom it was not fetched at. | [MultiRegionDisplayMixin](../multiregiondisplaymixin#action-fetchregions) | | **afterAttach**
() => void | installs the fetch-lifecycle autoruns (DisplayedRegionsChange, FetchVisibleRegions, SettingsInvalidate, ClearBlockingStateOnViewportChange) | [MultiRegionDisplayMixin](../multiregiondisplaymixin#action-afterattach) | | **setByteEstimate**
(measurement: { bytes: number; viewport: GateViewport; }) => void
| The bytes half of a measurement alone, for a test staging a display. Production commits through `commitFetchBytes`. | [RegionTooLargeMixin](../regiontoolargemixin#action-setbyteestimate) | | **clearByteEstimate**
() => void | Drops the estimate and the viewport stamp. `forceLoadTrack` survives: it is a track-wide approval. | [RegionTooLargeMixin](../regiontoolargemixin#action-clearbyteestimate) | | **setForceLoadTrack**
(flag: boolean) => void | | [RegionTooLargeMixin](../regiontoolargemixin#action-setforceloadtrack) | | **commitFetchBytes**
(perRegionBytes: (number | undefined)[], issued: GateFetchState) => void
| The byte axis of a finished fetch, called by the fetch runners with the `gateFetchState()` they captured at issue. Commits the per-region max; an empty batch, or an ungated display, commits nothing. | [RegionTooLargeMixin](../regiontoolargemixin#action-commitfetchbytes) | | **forceLoad**
() => void | The banner's button: exempt the track on both axes and refetch. | [RegionTooLargeMixin](../regiontoolargemixin#action-forceload) | | **markCanvasDrawn**
() => void | | [RenderLifecycleMixin](../renderlifecyclemixin#action-markcanvasdrawn) | | **resetCanvasDrawn**
() => void | | [RenderLifecycleMixin](../renderlifecyclemixin#action-resetcanvasdrawn) | | **stopRenderingBackend**
() => void | | [RenderLifecycleMixin](../renderlifecyclemixin#action-stoprenderingbackend) | | **renderNow**
() => void | | [RenderLifecycleMixin](../renderlifecyclemixin#action-rendernow) | | **setRenderError**
(error: unknown) => void | set/clear the render-backend error. Called by `useRenderingBackend`: with the error when the canvas factory rejects (or context-loss re-init fails), and with `undefined` on successful (re)init and on retry. | [RenderLifecycleMixin](../renderlifecyclemixin#action-setrendererror) | | **attachRenderingBackend**
<B>(backend: B, setup: () => RenderingBackendCallbacks<B>) => void
| attach a GPU/Canvas2D backend and install the upload + render autorun pair. Idempotent: re-calling swaps the backend and does not run `setup` again, so the callbacks and everything they close over are the first call's. | [RenderLifecycleMixin](../renderlifecyclemixin#action-attachrenderingbackend) | | **stopActiveFetch**
() => void | Abort the in-flight fetch (if any) and retire its slot. The shared preamble of both cancel paths; the difference between them is only what they do to `fetchCanceled` / `fetchGeneration` afterward. | [FetchMixin](../fetchmixin#action-stopactivefetch) | | **openStatusStream**
(isCurrent: () => boolean) => StatusStream | Open one operation's slot on the display's status field: an RPC `statusCallback` throttled through the display-wide window and guarded so a callback that fires after the node is torn down (RPCs resolve their status stream asynchronously) is a safe no-op, plus the `clear` that retires the slot when the operation ends.

**Every operation on the display opens one**, and the two come back together because an operation that never retires goes on voting for a phase that is over. The viewport fetch (`runFetch`), the clustering run and a lent `createStopTokenRotation` are three of them on one field; before ADR-081 each blanked the field outright and the last one to finish decided what the other two were still saying.

`isCurrent` is required and has no "node is alive" default, because alive is not the interesting question: a *superseded* fetch is on a live node, and its late status repainting the overlay of the fetch that replaced it is the failure this guards. `runFetch` passes `!isStale()`, which is what every display gets for free through `ctx.statusCallback`; a caller outside a fetch (the clustering autorun) passes its own run's flag. Defaulting to `isAlive` made the loose answer the easy one and five displays took it.

Declared this early only so `runFetch` can put one on every `FetchContext`. | [FetchMixin](../fetchmixin#action-openstatusstream) | | **cancelFetch**
() => void | cancel any in-flight fetch and bump fetchGeneration (always bumps, so callers can retrigger fetch autoruns even when nothing was in flight). This is the *internal* reset `clearAllRpcData` runs — it clears any user-cancel flag so the retrigger actually re-fetches. | [FetchMixin](../fetchmixin#action-cancelfetch) | | **cancelFetchByUser**
() => void | User-initiated cancel from the loading overlay. Stops the in-flight fetch and lands in a durable `fetchCanceled` state. Unlike `cancelFetch`, it does NOT bump fetchGeneration — so the fetch autoruns don't immediately restart the load. The user retries via `reload` (the overlay's retry button), or it clears on the next viewport change. | [FetchMixin](../fetchmixin#action-cancelfetchbyuser) | | **beforeDestroy**
() => void | Release an in-flight fetch's stop token on teardown. Without this, a display destroyed mid-fetch (track/view closed while loading) never signals the worker to abort the now-useless work, and its in-flight HTTP reads keep downloading. MST auto-chains lifecycle hooks, so a composing display can still define its own beforeDestroy. | [FetchMixin](../fetchmixin#action-beforedestroy) | | **endFetch**
(current: boolean, stopToken: StopToken) => void | The `finally` half of `runFetch`'s bookkeeping, an action of its own because `runFetchOnce`'s `finally` resumes on a microtask the flow does not own — a direct volatile write there is outside the action context, which is the one thing hoisting the sequence into a shared function costs. The stale branch is a superseded fetch: whoever superseded it — a newer `begin`, or `cancel` — already released this token. | [FetchMixin](../fetchmixin#action-endfetch) | | **runFetch**
(work: (ctx: FetchContext) => Promise<void>) => Promise<void> | Run a cancel-safe fetch (cancels any prior). The work callback gets a FetchContext with a stopToken to forward to the RPC and an isStale() check to short-circuit commits once the user has moved on.

**The MST-flow wrapper over the shared `runFetchOnce` sequence**, and only the wrapper: the begin/clear/run/commit/error/end order, and the rules that keep a superseded run from writing back, are the same function every other fetch in the tree runs. What this adds is the observable bookkeeping a display needs — `isLoading` through `activeStopToken`, `fetchGeneration`, the user-cancel clear — and the flow itself, which is an action, so `work`'s synchronous prefix runs untracked wherever a fetch autorun calls this. | [FetchMixin](../fetchmixin#action-runfetch) | | **setDensityStats**
(displayedRegionIndex: number, stats: RegionDensityStats) => void
| | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#action-setdensitystats) | | **clearGateMeasurements**
() => void | | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#action-cleargatemeasurements) | | **commitGateMeasurements**
(measurements: RegionGateMeasurement[], issued: GateFetchState) => void
| Commit a batch of per-region fetch results on the density axis, judged by the tier captured at issue. The byte axis is `commitFetchBytes`. | [CanvasFeatureGateMixin](../canvasfeaturegatemixin#action-commitgatemeasurements) | | **setShowLegend**
(arg: boolean) => void | | [LegendMixin](../legendmixin#action-setshowlegend) | | **setRowHeight**
(n: number) => void | Pin a px row height. `0` is the fit sentinel, but enter fit mode through `setFitToHeight` instead — displays whose `height` getter is content-derived have to re-seed the slot on the way in, and that is what the action is for. | [RowHeightMixin](../rowheightmixin#action-setrowheight) | | **setShowTree**
(arg: boolean) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setshowtree) | | **setShowBranchLength**
(arg: boolean) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setshowbranchlength) | | **setShowRowLabels**
(arg: boolean) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setshowrowlabels) | | **setLayout**
(layout: S[]) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setlayout) | | **clearLayout**
() => void | | [TreeSidebarMixin](../treesidebarmixin#action-clearlayout) | | **setClusterTree**
(tree?: string | undefined) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setclustertree) | | **setLayoutAndClusterTree**
(layout: S[], tree?: string | undefined, provenance?: ClusterProvenance | undefined) => void
| | [TreeSidebarMixin](../treesidebarmixin#action-setlayoutandclustertree) | | **setTreeAreaWidth**
(width: number) => void | | [TreeSidebarMixin](../treesidebarmixin#action-settreeareawidth) | | **setSubtreeFilter**
(names?: string[] | undefined) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setsubtreefilter) | | **setRunClustering**
(arg?: boolean | undefined) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setrunclustering) | | **setClusterRegion**
(arg?: string | undefined) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setclusterregion) | | **setSortRowsBy**
(arg?: RowSortSpec | undefined) => void | Trigger (or clear) a one-shot declarative row sort; consumed and reset by `setupRowSortAutorun`. A display's right-click item calls its own sort directly (instant, the data is already loaded); this is the session-level entry point. | [TreeSidebarMixin](../treesidebarmixin#action-setsortrowsby) | | **setHoveredTreeNode**
(node?: HoveredTreeNode | undefined) => void | | [TreeSidebarMixin](../treesidebarmixin#action-sethoveredtreenode) | | **setTreeCanvasRef**
(ref: HTMLCanvasElement | null) => void | | [TreeSidebarMixin](../treesidebarmixin#action-settreecanvasref) | | **setMouseoverCanvasRef**
(ref: HTMLCanvasElement | null) => void | | [TreeSidebarMixin](../treesidebarmixin#action-setmouseovercanvasref) | | **openContextMenu**
(info: Info) => void | | [ContextMenuMixin](../contextmenumixin#action-opencontextmenu) | | **closeContextMenu**
() => void | | [ContextMenuMixin](../contextmenumixin#action-closecontextmenu) |