Skip to content

API: expose panel/sidebar/auxiliaryBar visibility state to extensions #321409

@cgaspard

Description

@cgaspard

Problem

There is no public Extension API to query whether the sidebar, panel (bottom), or auxiliary bar are currently visible. The internal IWorkbenchLayoutService has exactly what's needed — isVisible("workbench.parts.sidebar") and onDidChangePartVisibility — but neither is bridged to the extension host.

As a result, extensions that need to save and restore layout state (e.g. a "maximize editor" toggle) have no reliable way to read the current visibility of these three parts. The only workaround is to parse VS Code's internal SQLite database (state.vscdb) directly, which is fragile and reads stale data mid-session.

The layout buttons in the VS Code title bar already track this state correctly because they run in the renderer process with direct access to the layout service. Extensions cannot do the same.

Proposed API

Add to vscode.window:

/**
 * Whether the primary sidebar is currently visible.
 */
readonly isSideBarVisible: boolean;

/**
 * Whether the bottom panel is currently visible.
 */
readonly isPanelVisible: boolean;

/**
 * Whether the auxiliary bar (secondary sidebar) is currently visible.
 */
readonly isAuxiliaryBarVisible: boolean;

/**
 * Fired when the visibility of the sidebar, panel, or auxiliary bar changes.
 */
readonly onDidChangeLayoutVisibility: Event<{
  sideBar: boolean;
  panel: boolean;
  auxiliaryBar: boolean;
}>;

Use Case

A "maximize editor" extension needs to:

  1. Read current visibility of all three parts before hiding them
  2. Restore only the parts that were originally visible

Without this API, if the user hides the bottom panel manually before pressing maximize, the extension has no way to know — and incorrectly restores it on unmaximize.

This is a general-purpose API gap: any extension that interacts with workbench layout (focus modes, presentation modes, Zen-like toggles) hits the same wall.

Current Workaround (and why it's bad)

Read ~/.config/Code/User/workspaceStorage/<hash>/state.vscdb directly via a custom SQLite B-tree parser. Problems:

  • Only accurate at window open (VS Code flushes the DB on close, not on toggle)
  • Relies on undocumented internal key names (workbench.sideBar.hidden, etc.)
  • Breaks if VS Code changes its storage format

Prior Art

  • Context keys sideBarVisible, panelVisible, auxiliaryBarVisible already exist internally and are kept in sync via onDidChangePartVisibility
  • These are used in when clauses in package.json but cannot be read at runtime by extension code
  • Exposing them (or wrapping isVisible()) would be a small bridge with high utility

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions