@jbrowse/app-core 5.0.0-beta.7 → 5.0.0-beta.9

package/esm/SessionSpec/index.d.ts

@@ -1,5 +1,5 @@
 export { buildLgvInit, buildLgvInitFromParams, hubConnectionSpec, readHubUrlParam, readNavParam, readTracklistParam, shortHubLabel, splitHighlights, } from './lgvUrlInit.ts';
-export { addSessionTracks, loadSessionSpec } from './loadSessionSpec.ts';
+export { addSessionTracks, launchSpecView, launchableSpecView, loadSessionSpec, viewTypeProblem, } from './loadSessionSpec.ts';
 export { parseSessionSpecUrl } from './parseSessionSpecUrl.ts';
 export type { LgvUrlInit } from './lgvUrlInit.ts';
 export type { ParsedSessionSpec } from './parseSessionSpecUrl.ts';

package/esm/SessionSpec/index.js

@@ -1,3 +1,3 @@
 export { buildLgvInit, buildLgvInitFromParams, hubConnectionSpec, readHubUrlParam, readNavParam, readTracklistParam, shortHubLabel, splitHighlights, } from './lgvUrlInit.js';
-export { addSessionTracks, loadSessionSpec } from './loadSessionSpec.js';
+export { addSessionTracks, launchSpecView, launchableSpecView, loadSessionSpec, viewTypeProblem, } from './loadSessionSpec.js';
 export { parseSessionSpecUrl } from './parseSessionSpecUrl.js';

package/esm/SessionSpec/loadSessionSpec.d.ts

@@ -11,11 +11,67 @@ import type { AbstractSessionModel } from '@jbrowse/core/util';
  * layer down.
  */
 export declare function addSessionTracks(session: AbstractSessionModel | undefined, tracks: Record<string, unknown>[]): void;
-export declare function loadSessionSpec({ views, sessionAssemblies, sessionConnections, sessionTracks, layout, sessionName, }: {
+export declare function unknownViewTypesMessage(types: string[]): string;
+export declare function noLauncherMessage(types: string[]): string;
+/**
+ * Why one view type cannot launch from a spec here, or nothing. Two causes,
+ * two messages: the type is unknown at all (a typo, or a plugin that was not
+ * loaded), or it exists but nothing taught it how to launch from a spec, which
+ * only the view's plugin can fix.
+ */
+export declare function viewTypeProblem(pluginManager: PluginManager, type: string): string | undefined;
+/**
+ * A spec view entry as its launcher takes it, and what its type does not take.
+ *
+ * The same classification a view snapshot gets, run here because a spec never
+ * becomes one: `LaunchView-<type>` takes these keys as arguments, so
+ * `withLaunchInput`'s partition never sees them and nothing names a typo.
+ * `{type: 'LinearGenomeView', asembly: 'volvox'}` reported only the launcher's
+ * downstream "No assembly provided", on the one surface written by hand with no
+ * compiler and no editor behind it.
+ *
+ * A view type that registers no launch keys classifies nothing: its launcher's
+ * vocabulary is undeclared, so every argument would read as a typo. A lazily
+ * registered type declares its properties on a state model that is not loaded
+ * yet, so it is loaded first — the launch would have loaded it anyway.
+ */
+export declare function launchableSpecView(pluginManager: PluginManager, spec: ViewSpec): Promise<{
+    view: ViewSpec;
+    problem?: string;
+}>;
+/**
+ * Launch one spec view into the session through its `LaunchView-<type>`
+ * extension point, the same door `loadSessionSpec` uses for each of its views
+ * — so `jb.addView` and a spec agree on what a view entry means, a
+ * ProteinView's `connectedView` included.
+ *
+ * Strict so a launch handler that throws (missing/invalid assembly, unresolved
+ * track, ...) is returned as a failure instead of being swallowed by the plain
+ * extension-point runner, which would leave a silent empty session. A handler
+ * that legitimately no-ops returns normally and is unaffected.
+ *
+ * `created` is EVERY view the launch added, in creation order: a connected
+ * ProteinView creates its genome view and then itself. `view` is the entry's
+ * own, the one of the spec's type, which is where `displayName` goes — it used
+ * to land on the genome view a ProteinView opened first, and the structure came
+ * up "Untitled view". `type` is the dispatch key, not a setting: forwarding it
+ * would land in the view's launch blob and trip the "ignored unknown key(s):
+ * type" warning meant to catch typos.
+ */
+export declare function launchSpecView(session: AbstractSessionModel | undefined, pluginManager: PluginManager, spec: ViewSpec): Promise<{
+    created: import("@jbrowse/core/util").AbstractViewModel[];
+    view: import("@jbrowse/core/util").AbstractViewModel | undefined;
+    failure?: {
+        message: string;
+        cause: unknown;
+    } | undefined;
+}>;
+export interface SessionSpec {
     views: ViewSpec[];
     sessionAssemblies?: Record<string, unknown>[];
     sessionConnections?: Record<string, unknown>[];
     sessionTracks?: Record<string, unknown>[];
     layout?: LayoutNode;
     sessionName?: string;
-}, pluginManager: PluginManager): Promise<void>;
+}
+export declare function loadSessionSpec(spec: SessionSpec, pluginManager: PluginManager): Promise<void>;

package/esm/SessionSpec/loadSessionSpec.js

@@ -156,15 +156,159 @@ function flattenedTabsContainers(layout) {
     const nestedTabsChild = layout.direction === 'tabs' && children.some(c => c.children !== undefined);
     return nestedTabsChild || children.some(flattenedTabsContainers);
 }
-// use extension point named e.g. LaunchView-LinearGenomeView to initialize an
-// LGV session
-export async function loadSessionSpec({ views, sessionAssemblies = [], sessionConnections = [], sessionTracks = [], layout, sessionName, }, pluginManager) {
+export function unknownViewTypesMessage(types) {
+    return `Unknown view type(s) in session spec: ${types.join(', ')}. The plugin providing the view may be missing, or the type may be misspelled.`;
+}
+export function noLauncherMessage(types) {
+    return `View type(s) ${types.join(', ')} cannot be launched from a session spec: no LaunchView extension point is registered for them.`;
+}
+/**
+ * Why one view type cannot launch from a spec here, or nothing. Two causes,
+ * two messages: the type is unknown at all (a typo, or a plugin that was not
+ * loaded), or it exists but nothing taught it how to launch from a spec, which
+ * only the view's plugin can fix.
+ */
+export function viewTypeProblem(pluginManager, type) {
+    if (pluginManager.extensionPoints.has(`LaunchView-${type}`)) {
+        return undefined;
+    }
+    // the record's `has`, not getElementType, which throws on an unregistered
+    // name rather than returning undefined
+    return pluginManager.getElementTypeRecord('view').has(type)
+        ? noLauncherMessage([type])
+        : unknownViewTypesMessage([type]);
+}
+// v4 nested a view's settings under `init`. A spec never becomes a snapshot, so
+// `withLaunchInput`'s unwrap never runs on one and this surface does it itself,
+// in the same order: the flat spelling wins.
+function flattenSpecView(spec) {
+    const { init, ...view } = spec;
+    if (init) {
+        console.warn(legacyInitMessage(view.type));
+    }
+    return init ? { ...init, ...view } : view;
+}
+/**
+ * A spec view entry as its launcher takes it, and what its type does not take.
+ *
+ * The same classification a view snapshot gets, run here because a spec never
+ * becomes one: `LaunchView-<type>` takes these keys as arguments, so
+ * `withLaunchInput`'s partition never sees them and nothing names a typo.
+ * `{type: 'LinearGenomeView', asembly: 'volvox'}` reported only the launcher's
+ * downstream "No assembly provided", on the one surface written by hand with no
+ * compiler and no editor behind it.
+ *
+ * A view type that registers no launch keys classifies nothing: its launcher's
+ * vocabulary is undeclared, so every argument would read as a typo. A lazily
+ * registered type declares its properties on a state model that is not loaded
+ * yet, so it is loaded first — the launch would have loaded it anyway.
+ */
+export async function launchableSpecView(pluginManager, spec) {
+    const flat = flattenSpecView(spec);
+    if (!pluginManager.getElementTypeRecord('view').has(flat.type)) {
+        return { view: flat };
+    }
+    const viewType = pluginManager.getViewType(flat.type);
+    await viewType.loadStateModel();
+    const accepted = viewType.acceptedKeys;
+    if (!accepted) {
+        return { view: flat };
+    }
+    const { view, problem } = readAssemblyNames(flat, accepted);
+    const { type, ...keyed } = view;
+    const unknown = Object.keys(keyed).filter(key => !accepted.includes(key));
+    const problems = [
+        ...(unknown.length ? [unknownKeysMessage(type, unknown)] : []),
+        ...(problem ? [problem] : []),
+    ];
+    return { view, problem: problems.join('; ') || undefined };
+}
+// An agent reads `assemblyNames` off the live view and writes it back into a
+// spec, where the key the entry takes is `assembly`. One name is that assembly;
+// several are a question one view cannot answer.
+function readAssemblyNames(view, accepted) {
+    const { assemblyNames, ...rest } = view;
+    // Array.isArray, not a length check: a hand-written `assemblyNames: 'volvox'`
+    // has a length too, and reached .join below — a throw, which this one outer
+    // catch turns into every remaining view and the layout being lost
+    if (!Array.isArray(assemblyNames) ||
+        !assemblyNames.length ||
+        !accepted.includes('assembly') ||
+        accepted.includes('assemblyNames')) {
+        return { view };
+    }
+    return assemblyNames.length === 1
+        ? { view: { ...rest, assembly: rest.assembly ?? assemblyNames[0] } }
+        : {
+            view: rest,
+            problem: `${view.type} takes one "assembly", and assemblyNames names ${assemblyNames.length} (${assemblyNames.join(', ')}) — pass assembly, one view per assembly`,
+        };
+}
+/**
+ * Launch one spec view into the session through its `LaunchView-<type>`
+ * extension point, the same door `loadSessionSpec` uses for each of its views
+ * — so `jb.addView` and a spec agree on what a view entry means, a
+ * ProteinView's `connectedView` included.
+ *
+ * Strict so a launch handler that throws (missing/invalid assembly, unresolved
+ * track, ...) is returned as a failure instead of being swallowed by the plain
+ * extension-point runner, which would leave a silent empty session. A handler
+ * that legitimately no-ops returns normally and is unaffected.
+ *
+ * `created` is EVERY view the launch added, in creation order: a connected
+ * ProteinView creates its genome view and then itself. `view` is the entry's
+ * own, the one of the spec's type, which is where `displayName` goes — it used
+ * to land on the genome view a ProteinView opened first, and the structure came
+ * up "Untitled view". `type` is the dispatch key, not a setting: forwarding it
+ * would land in the view's launch blob and trip the "ignored unknown key(s):
+ * type" warning meant to catch typos.
+ */
+export async function launchSpecView(session, pluginManager, spec) {
+    const { type, displayName, ...view } = spec;
+    const before = new Set(session?.views.map(v => v.id));
+    let failure;
+    try {
+        await pluginManager.evaluateAsyncExtensionPointStrict(`LaunchView-${type}`, {
+            ...view,
+            session,
+        });
+    }
+    catch (e) {
+        console.error(e);
+        failure = { message: `Failed to launch ${type} view: ${e}`, cause: e };
+    }
+    const created = session?.views.filter(v => !before.has(v.id)) ?? [];
+    const named = created.find(v => v.type === type) ?? created[0];
+    if (named && displayName) {
+        named.setDisplayName(displayName);
+    }
+    return { created, view: named, ...(failure ? { failure } : {}) };
+}
+const SPEC_KEYS = [
+    'views',
+    'sessionAssemblies',
+    'sessionConnections',
+    'sessionTracks',
+    'layout',
+    'sessionName',
+];
+export async function loadSessionSpec(spec, pluginManager) {
+    const { views, sessionAssemblies = [], sessionConnections = [], sessionTracks = [], layout, sessionName, } = spec;
     const rootModel = pluginManager.rootModel;
     try {
         rootModel.setSession?.({
             name: sessionName ?? `New session ${new Date().toLocaleString()}`,
         });
         const { session } = rootModel;
+        // `tracks` for sessionTracks, `assemblies` for sessionAssemblies, `name`
+        // for sessionName: a top-level key this spec does not define used to be
+        // dropped by the destructure above with nothing said, on the one door every
+        // agent-facing text names first. Reported like the misplaced keys below,
+        // rather than thrown, so the rest of the spec still loads.
+        const unknownKeys = Object.keys(spec).filter(key => !SPEC_KEYS.includes(key));
+        if (unknownKeys.length) {
+            session?.notifyError(`${unknownKeysMessage('Session spec', unknownKeys)} — it takes ${SPEC_KEYS.join(', ')}`);
+        }
         // Assemblies first: sessionTracks and the views below reference them by
         // name, so a self-contained spec (novel assemblies + their tracks, no
         // hosted config) resolves only if the assemblies exist before either runs.
@@ -217,82 +361,21 @@ export async function loadSessionSpec({ views, sessionAssemblies = [], sessionCo
             }
         }
         addSessionTracks(session, sessionTracks);
-        // a view type with no registered LaunchView-<type> extension point makes
+        // A view type with no registered LaunchView-<type> extension point makes
         // evaluateAsyncExtensionPoint a silent no-op, leaving an empty session with
-        // no diagnostic. Two different causes, so two messages: the view type is
-        // unknown here at all (a typo, or a plugin that wasn't loaded), or it exists
-        // but nothing taught it how to launch from a spec, which the spec author
-        // can't fix, only the view's plugin can.
+        // no diagnostic. Reported once per type, not per view.
+        const viewTypes = pluginManager.getElementTypeRecord('view');
         const notLaunchable = [
-            ...new Set(views.flatMap(view => pluginManager.extensionPoints.has(`LaunchView-${view.type}`)
-                ? []
-                : [view.type])),
+            ...new Set(views.flatMap(view => viewTypeProblem(pluginManager, view.type) ? [view.type] : [])),
         ];
-        // the record's `has`, not getElementType, which throws on an unregistered
-        // name rather than returning undefined
-        const viewTypes = pluginManager.getElementTypeRecord('view');
         const unknown = notLaunchable.filter(type => !viewTypes.has(type));
         const noLauncher = notLaunchable.filter(type => viewTypes.has(type));
         if (unknown.length) {
-            session?.notifyError(`Unknown view type(s) in session spec: ${unknown.join(', ')}. The plugin providing the view may be missing, or the type may be misspelled.`);
+            session?.notifyError(unknownViewTypesMessage(unknown));
         }
         if (noLauncher.length) {
-            session?.notifyError(`View type(s) ${noLauncher.join(', ')} cannot be launched from a session spec: no LaunchView extension point is registered for them.`);
-        }
-        // v4 nested a view's settings under `init`. A spec never becomes a
-        // snapshot, so `withLaunchInput`'s unwrap never runs on one and this
-        // surface does it itself, in the same order: the flat spelling wins.
-        const specViews = views.map(({ init, ...view }) => {
-            if (init) {
-                console.warn(legacyInitMessage(view.type));
-            }
-            return init ? { ...init, ...view } : view;
-        });
-        // The same classification a view snapshot gets, run here because a spec
-        // never becomes one: `LaunchView-<type>` takes these keys as arguments, so
-        // `withLaunchInput`'s partition never sees them and nothing names a typo.
-        // `{type: 'LinearGenomeView', asembly: 'volvox'}` reported only the
-        // launcher's downstream "No assembly provided", on the one surface written
-        // by hand with no compiler and no editor behind it.
-        //
-        // An ERROR rather than the snapshot path's warning: this surface's
-        // misplaced keys already report as errors, and the launcher's own failure
-        // lands as an error a line later — a warning under it reads as the lesser
-        // of the two, when it is the cause.
-        //
-        // A view type that registers no launch keys classifies nothing: its
-        // launcher's vocabulary is undeclared, so every argument would read as a
-        // typo.
-        //
-        // A lazily registered view type declares its properties on a state model
-        // that is not loaded yet, so it is loaded first — the launch below would
-        // have loaded it anyway.
-        await Promise.all(specViews
-            .filter(({ type }) => viewTypes.has(type))
-            .map(({ type }) => pluginManager.getViewType(type).loadStateModel()));
-        for (const { type, ...view } of specViews) {
-            const accepted = viewTypes.has(type)
-                ? pluginManager.getViewType(type).acceptedKeys
-                : undefined;
-            const unknown = accepted
-                ? Object.keys(view).filter(key => !accepted.includes(key))
-                : [];
-            if (unknown.length) {
-                session?.notifyError(unknownKeysMessage(type, unknown));
-            }
+            session?.notifyError(noLauncherMessage(noLauncher));
         }
-        // Launch sequentially and record the id each spec view created, so the
-        // layout below can map its indices to real views. Reading session.views
-        // positionally afterwards only works while every handler happens to addView
-        // synchronously and in order; capturing the delta per launch instead is
-        // correct even if a handler awaits or adds an auxiliary view, and lets a
-        // later spec view (e.g. a connected MsaView) reference an earlier one that
-        // now already exists. `type` is the dispatch key, not a setting: forwarding
-        // it would land in the view's launch blob and trip the spurious
-        // "ignored unknown key(s): type" warning meant to catch typos.
-        // `displayName` is applied here rather than forwarded because it is a base
-        // view prop every view type has, so one path covers all of them (including
-        // plugin-provided types whose launcher never heard of it).
         // Let any connection this spec registered finish before the views that
         // reference what it supplies are launched (see whenConnectionsSettle). Gated
         // on there being views: with none, nothing is waiting on the connection, and
@@ -306,31 +389,28 @@ export async function loadSessionSpec({ views, sessionAssemblies = [], sessionCo
             !(await whenConnectionsSettle(session))) {
             return;
         }
+        // Launch sequentially and record the ids each spec view created, so the
+        // layout below can map its indices to real views. Reading session.views
+        // positionally afterwards only works while every handler happens to addView
+        // synchronously and in order; capturing the delta per launch instead is
+        // correct even if a handler awaits or adds an auxiliary view, and lets a
+        // later spec view (e.g. a connected MsaView) reference an earlier one that
+        // now already exists.
+        //
+        // An unknown key is an ERROR rather than the snapshot path's warning: this
+        // surface's misplaced keys already report as errors, and the launcher's own
+        // failure lands as an error a line later — a warning under it reads as the
+        // lesser of the two, when it is the cause. Per view, so one bad view
+        // doesn't cost the rest.
         const createdViewIds = [];
-        for (const { type, displayName, ...view } of specViews) {
-            const before = new Set(session?.views.map(v => v.id));
-            // Strict so a launch handler that throws (missing/invalid assembly,
-            // unresolved track, ...) surfaces as a snackbar instead of being swallowed
-            // by the plain extension-point runner, which would leave a silent empty
-            // session. A handler that legitimately no-ops returns normally and is
-            // unaffected. Per-view try/catch so one bad view doesn't abort the rest.
-            try {
-                await pluginManager.evaluateAsyncExtensionPointStrict(`LaunchView-${type}`, {
-                    ...view,
-                    session,
-                });
-            }
-            catch (e) {
-                console.error(e);
-                session?.notifyError(`Failed to launch ${type} view: ${e}`, e);
+        for (const spec of views) {
+            const { view, problem } = await launchableSpecView(pluginManager, spec);
+            if (problem) {
+                session?.notifyError(problem);
             }
-            const created = session?.views.filter(v => !before.has(v.id)) ?? [];
-            // The entry's own view, when its launcher created others beside it: a
-            // connected ProteinView's name went to the genome view it opened first,
-            // and the structure came up "Untitled view".
-            const named = created.find(v => v.type === type) ?? created[0];
-            if (named && displayName) {
-                named.setDisplayName(displayName);
+            const { created, failure } = await launchSpecView(session, pluginManager, view);
+            if (failure) {
+                session?.notifyError(failure.message, failure.cause);
             }
             createdViewIds.push(created.map(v => v.id));
         }

package/esm/SessionSpec/types.d.ts

@@ -6,6 +6,12 @@ export interface ViewSpec {
     displayName?: string;
     tracks?: TrackInit[];
     assembly?: string;
+    /**
+     * The live view's spelling of the key above, accepted because that is where
+     * a spec gets written from: one name is the `assembly`, and several are
+     * refused naming it.
+     */
+    assemblyNames?: string[];
     loc?: string;
     /**
      * @deprecated v4's nesting. Write every setting directly on the view object;

package/esm/WorkspaceLayout/model.d.ts

@@ -243,14 +243,14 @@ export declare function WorkspaceLayoutMixin(): import("@jbrowse/mobx-state-tree
     tileViews(mode: TileMode, allViewIds: string[]): void;
     /**
      * #action
-     * Arrange the session's views into panels: `applyLayoutSpec` plus the
-     * two things it does not do on its own, each of which fails silently
-     * without it — turning workspaces mode on for this session (a layout
-     * renders nowhere else) and ordering `session.views` to the spec's
-     * top-to-bottom statement, which is where a tab reads its order from.
-     * Leaves take view ids or indexes into `session.views`; a layout that
-     * seats no view throws rather than leaving a blank tab. What a session
-     * spec's `layout` and an agent's live re-layout both call.
+     * Arrange the session's views into panels. Calls `applyLayoutSpec`,
+     * turns workspaces mode on for this session (a layout renders nowhere
+     * else), and orders `session.views` to the spec's top-to-bottom
+     * order, which tabs read their order from. Without the last two steps
+     * the layout applies but does not display, or the tabs appear in the
+     * wrong order. Leaves take view ids or indexes into `session.views`; a
+     * layout that seats no view throws rather than leaving a blank tab. A
+     * session spec's `layout` and an agent's live re-layout both call it.
      */
     layoutViews(spec: LayoutSpecNode): string[];
 }, import("@jbrowse/mobx-state-tree")._NotCustomized, import("@jbrowse/mobx-state-tree")._NotCustomized>;

package/esm/WorkspaceLayout/model.js

@@ -560,14 +560,14 @@ export function WorkspaceLayoutMixin() {
         },
         /**
          * #action
-         * Arrange the session's views into panels: `applyLayoutSpec` plus the
-         * two things it does not do on its own, each of which fails silently
-         * without it — turning workspaces mode on for this session (a layout
-         * renders nowhere else) and ordering `session.views` to the spec's
-         * top-to-bottom statement, which is where a tab reads its order from.
-         * Leaves take view ids or indexes into `session.views`; a layout that
-         * seats no view throws rather than leaving a blank tab. What a session
-         * spec's `layout` and an agent's live re-layout both call.
+         * Arrange the session's views into panels. Calls `applyLayoutSpec`,
+         * turns workspaces mode on for this session (a layout renders nowhere
+         * else), and orders `session.views` to the spec's top-to-bottom
+         * order, which tabs read their order from. Without the last two steps
+         * the layout applies but does not display, or the tabs appear in the
+         * wrong order. Leaves take view ids or indexes into `session.views`; a
+         * layout that seats no view throws rather than leaving a blank tab. A
+         * session spec's `layout` and an agent's live re-layout both call it.
          */
         layoutViews(spec) {
             const host = layoutHost(self);

package/esm/ui/App/App.js

@@ -2,11 +2,10 @@ import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
 import { Suspense, lazy } from 'react';
 import Snackbar from '@jbrowse/core/ui/Snackbar';
 import { makeStyles } from '@jbrowse/core/util/tss-react';
-import { ModalWidget, drawerGridTemplateColumns } from '@jbrowse/product-core';
+import { AppReadyMarker, ModalWidget, drawerGridTemplateColumns, } from '@jbrowse/product-core';
 import { AppBar } from '@mui/material';
 import { observer } from 'mobx-react';
 import AppFab from './AppFab.js';
-import AppReadyMarker from './AppReadyMarker.js';
 import AppToolbar from './AppToolbar.js';
 import DialogQueue from './DialogQueue.js';
 import ViewsContainer from './ViewsContainer.js';

package/esm/ui/App/ViewStack.js

@@ -10,6 +10,12 @@ import ViewContainer from './ViewContainer.js';
 // the amount that makes that gesture reach, and any more is room to scroll the
 // content off its own surface.
 //
+// It is scrollable room rather than content, so anything measuring how tall the
+// session is discounts it by its `view-stack-overscroll` testid — `overflow` in
+// jbApi does, and a filmed take paid for that: counted as content, it told
+// `jb.fitToWindow` the session was 300px taller than it was, and the dotplot
+// absorbing the cut came out a third of the height that fit.
+//
 // Capped, because half a port stops being a courtesy on a tall screen. 300px is
 // the cap the classic stack has always had and it stays the answer there — a
 // full window is comfortably past twice it. What the cap was hiding is the
@@ -37,6 +43,6 @@ const ViewStack = observer(function ViewStack({ views, session, className, }) {
     // restore / initial load), so they must not steal scroll when they mount. A
     // view whose id isn't in this set was added later and auto-scrolls into view.
     const [initialViewIds] = useState(() => new Set(views.map(v => v.id)));
-    return (_jsxs(_Fragment, { children: [_jsx("div", { ref: viewsRef, className: className, children: views.map(view => (_jsx(ViewContainer, { view: view, session: session, scrollOnMount: !initialViewIds.has(view.id) }, view.id))) }), scrollable ? _jsx("div", { className: classes.spacer }) : null] }));
+    return (_jsxs(_Fragment, { children: [_jsx("div", { ref: viewsRef, className: className, children: views.map(view => (_jsx(ViewContainer, { view: view, session: session, scrollOnMount: !initialViewIds.has(view.id) }, view.id))) }), scrollable ? (_jsx("div", { className: classes.spacer, "data-testid": "view-stack-overscroll" })) : null] }));
 });
 export default ViewStack;

package/esm/ui/App/index.d.ts

@@ -1,3 +1,3 @@
 export { App } from './App.tsx';
-export { default as AppReadyMarker } from './AppReadyMarker.tsx';
+export { AppReadyMarker } from '@jbrowse/product-core';
 export { default as DialogQueue } from './DialogQueue.tsx';

package/esm/ui/App/index.js

@@ -1,3 +1,3 @@
 export { App } from './App.js';
-export { default as AppReadyMarker } from './AppReadyMarker.js';
+export { AppReadyMarker } from '@jbrowse/product-core';
 export { default as DialogQueue } from './DialogQueue.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jbrowse/app-core",
-  "version": "5.0.0-beta.7",
+  "version": "5.0.0-beta.9",
   "type": "module",
   "description": "JBrowse 2 code shared between the 'full featured' apps e.g. jbrowse-web and jbrowse-desktop",
   "keywords": [
@@ -24,13 +24,13 @@
     "esm"
   ],
   "dependencies": {
-    "@jbrowse/mobx-state-tree": "^6.5.1",
+    "@jbrowse/mobx-state-tree": "^6.5.2",
     "@mui/icons-material": "^9.4.0",
     "@mui/material": "^9.4.0",
     "mobx": "^7.0.3",
     "mobx-react": "^10.0.2",
-    "@jbrowse/product-core": "^5.0.0-beta.7",
-    "@jbrowse/core": "^5.0.0-beta.7"
+    "@jbrowse/core": "^5.0.0-beta.9",
+    "@jbrowse/product-core": "^5.0.0-beta.9"
   },
   "peerDependencies": {
     "react": ">=19.0.0",

package/esm/ui/App/AppReadyMarker.d.ts

@@ -1,43 +0,0 @@
-import type { AppSession } from './types.ts';
-/**
- * One element that says whether the whole app has finished, and what is open.
- *
- * `[data-app-phase="ready"]` is the entire readiness contract for anything
- * driving JBrowse from outside — a screenshot tool, a test, an agent. Wait for
- * that selector and you are done; there is no chain to assemble and no
- * per-display census to take.
- *
- * Why it exists when `data-view-phase` and `data-display-phase` already do:
- * those are per-element and NEGATIVE. Asking them "is everything finished"
- * means asserting that no element carries the loading value, which is equally
- * true of an app that has not started — and the gap is real, measured at about
- * a second on a two-track session. A positive attribute cannot be satisfied
- * early, because something has to render it.
- *
- * The census attributes beside it — `data-app-views`, `data-app-assemblies`,
- * `data-app-tracks` (the latter two JSON arrays) — publish WHAT is open the
- * same way the phase publishes whether it is done, so an outside reader asking
- * "is the track I requested actually open" reads one element instead of
- * walking `window.JBrowseSession` with its own copy of the view nesting. The
- * walk itself is `openViews`/`openTracks` over each view's declared
- * `ownViews`/`ownTracks`, so this component knows nothing about which property
- * a container view keeps its children on either.
- *
- * Its own component, and `hidden`, for two reasons: an observer here subscribes
- * to every view's phase without re-rendering the app shell around it, and a
- * marker that is never drawn cannot be mistaken for UI or shift a layout. It is
- * still found by `querySelector`, which is what reads it.
- *
- * **What it is silent about**: a display in a TERMINAL state. `error` is a
- * finished state, so this reads `ready` over a display whose fetch failed —
- * correctly, since nothing is still working. A capture wants more than that: it
- * wants a picture, and an error banner is not one. `waitForDisplaysDone` after
- * this is what draws that line, keying on the `data-display-drawn` the two
- * comparative canvases publish from their stricter `settled` gate (see
- * `comparativeReadiness` in `@jbrowse/synteny-core`, which holds both answers
- * and says why an error separates them). Both harnesses do it in that order.
- */
-declare const AppReadyMarker: ({ session, }: {
-    session: AppSession;
-}) => import("react").JSX.Element;
-export default AppReadyMarker;