Expose atomic Session and conversation-view navigation for Web plugins

[TommyZeng777]

Summary

Web plugins can open a durable Session through ctx.sessions.open(sessionId), but they cannot atomically select the target Session's conversation view through a supported public API.

Discussion #2346 proposed this capability and was later marked as resolved and closed. However, neither dsh-v0.1.2-alpha.2 nor the current GitHub master exposes openSession(sessionId, viewId), selectView, or an equivalent method on IConversation.

I would like to clarify whether a replacement API already exists. If it does not, I propose exposing an atomic Session-and-view navigation operation for Web plugins.

Current limitation

The public API can activate a Session:

ctx.sessions.open(sessionId)

However, the active conversation.view is still owned by a private, per-Session ui-conversation store.

A plugin cannot reliably express:

open Session B and display its Chat view

as one supported operation.

Calling sessions.open(sessionB) may activate Session B while leaving it on its previously selected view, such as a plugin-provided custom view or the Trajectory view.

Real-world plugin impact

While developing a real out-of-tree Web plugin with multiple Session-scoped views, I found that returning to a target Session's official Chat view currently requires the plugin to:

• query [role="tab"] elements;
• identify tabs through localized visible labels;
• invoke DOM .click();
• use MutationObserver to wait for the target surface to mount;
• implement cancellation, timeouts, latest-wins behavior, and failure cleanup independently.

This workaround has caused several real regressions:

• the Session changed, but the visible view did not;
• navigation reported success while the old surface remained visible;
• the native New Session or Conversation page briefly flashed;
• competing navigation paths clicked the same tab repeatedly;
• DOM or label changes silently broke navigation;
• a delayed operation changed the view after a newer user intent had already completed.

These problems can affect any plugin that opens another Session and expects a particular target view.

Proposed public contract

One possible API shape is:

interface IConversation {
  openSession(
    sessionId: SessionId,
    viewId: string,
    options?: {
      signal?: AbortSignal
    },
  ): Promise<void>
}

Example:

await ctx.conversation.openSession(targetSessionId, 'chat', {
  signal: controller.signal,
})

The exact name and location are only suggestions. The important part is that one owner coordinates Session activation and view selection as a single transaction.

Expected behavior

The operation should:

1. validate that the target Session exists and is navigable;
2. retain the requested viewId if the target Session has not mounted yet;
3. activate the target Session at most once;
4. select the requested view after its registration and store are ready;
5. resolve only after the requested Session and view are actually active;
6. support cancellation through AbortSignal;
7. use latest-wins semantics for competing navigation requests;
8. prevent a cancelled or superseded request from changing the visible surface;
9. clean up pending state when Session activation fails;
10. fail with a typed or actionable error when the requested view does not exist.

The per-Session view store can remain private. Plugins only need the orchestration capability, not direct access to its implementation.

Relationship to existing discussions

• Proposal: public cross-session conversation view navigation for Web plugins #2346 requested public cross-Session conversation-view navigation, but it is now closed as resolved without an answer, comment, linked implementation, or documented replacement API.
• Session Presentation protocol v2: an additive API for showing more than one Session at once (client-side, backward compatible) #4718 proposes a broader multi-Session presentation protocol with visible and focused state.

This proposal is narrower than full multi-Session presentation. It addresses the atomic navigation operation required even when the interface continues to display only one Session at a time.

If #4718 becomes the preferred architecture, the same capability could be represented inside that protocol. For example:

await sessions.presentation.open(sessionId, {
  viewId: 'chat',
  signal,
})

Questions for maintainers

1. Which API or design made Proposal: public cross-session conversation view navigation for Web plugins #2346 resolved?
2. Is there already a supported way for a plugin to atomically select a Session and its target conversation.view?
3. If not, should this capability belong to ctx.conversation, ctx.sessions, or a broader presentation/navigation service?
4. Should the operation wait for the target view to mount, or return a navigation handle with observable completion?
5. Would maintainers prefer this request to remain separate from Session Presentation protocol v2: an additive API for showing more than one Session at once (client-side, backward compatible) #4718, or be incorporated into its presentation contract?

I can provide a minimal reproduction and sanitized acceptance cases if they would help define the contract.