Allow Stream Deck plugin windows to be resizable or dynamically sized at runtime

[seanp01]

Description

Stream Deck plugins can define a DefaultWindowSize in the manifest, but hosted plugin windows do not appear to honor runtime sizing controls such as window.open(..., "width=...,height=...,resizable=yes"), window.resizeTo(...), fullscreen requests, or user resizing.

This makes it difficult to build plugin-owned workspaces that need more flexible layouts, such as charting, dashboards, editors, monitoring views, or other interactive tools. In our case, we have a Chart Analysis workspace opened from a Stream Deck action. The manifest DefaultWindowSize works as a static initial size, but users cannot resize the window and the plugin cannot adjust the window dimensions based on action settings, device type, layout mode, or saved user preference.

It would be helpful if Stream Deck exposed an officially supported way for plugin windows to either:

• Opt into user-resizable hosted windows.
• Set or update hosted window size at runtime.
• Open plugin-owned windows with honored width, height, minWidth, minHeight, and resizable options.
• Optionally request maximize/fullscreen behavior where platform policy allows it.
• Even a manifest-level option such as ResizableWindow: true, or an SDK API such as streamDeck.windows.open({ path, width, height, resizable }), would make this much easier to implement reliably.

Examples

A plugin action opens a chart workspace:

const features = [
  "width=1280",
  "height=820",
  "minWidth=640",
  "minHeight=420",
  "resizable=yes",
  "maximizable=yes",
  "fullscreenable=yes",
  "scrollbars=yes"
].join(",");

window.open("chart-analysis.html", "TradingDeckChartAnalysisWindow", features);

The plugin manifest also defines:

{
  "DefaultWindowSize": [1280, 820]
}

Observed behavior:

DefaultWindowSize affects the initial hosted window size.
Changing width / height in window.open does not reliably affect the hosted window.
resizable=yes does not make the hosted window user-resizable.
window.resizeTo(width, height) is ignored.
Fullscreen/maximize requests are ignored.
Reusing a named window focuses the existing window but does not apply new size features.
Desired behavior:

The hosted plugin window can be made user-resizable, or
The plugin can dynamically set the hosted window size through a documented SDK/API, or
window.open feature values are honored for plugin-owned hosted windows when allowed by the manifest.
Use case:

A Stream Deck trading/charting plugin has a Chart Analysis workspace. Different users and devices need different window sizes. Some users want a compact 900x600 view; others want a larger 1600x1000 view. Today this can only be approximated by changing the plugin manifest DefaultWindowSize and redeploying/restarting the plugin, which is not suitable as a user-facing setting.

Impact

This limits the kinds of first-class plugin experiences developers can build inside Stream Deck’s hosted window system.

In my project, the affected workflow is a plugin-owned analysis workspace opened from a Stream Deck action. A static manifest DefaultWindowSize works for one default layout, but it does not cover real user needs:

Users with small displays may need a compact workspace window.
Users with large or ultrawide displays may want a larger analysis workspace.
Stream Deck users may want a window size that better matches encoder-driven controls.
Accessibility users may need more space for larger text, denser controls, or reduced scrolling.
Plugin authors cannot save and restore a user’s preferred hosted window size reliably.
Per-action settings cannot control the hosted window size, even when the setting is stored correctly.
Reusing a named plugin window focuses the existing window but does not apply a new size.
The result is that plugin developers either ship one fixed-size hosted window for everyone or avoid richer hosted windows entirely. For charting, monitoring dashboards, editors, logs, configuration tools, and data-heavy workflows, this is a significant UX constraint.

Alternatives Considered

Use manifest DefaultWindowSize
This is the only approach that has worked reliably so far.

{
  "DefaultWindowSize": [1280, 820]
}

Limitation: it is static, plugin-level, and requires changing the manifest, redeploying, and restarting to adjust. It cannot support per-user or per-action sizing.

Use [window.open] feature flags
Example:

window.open(
  "analysis-workspace.html",
  "MyPluginAnalysisWindow",
  "width=1280,height=820,resizable=yes,maximizable=yes,fullscreenable=yes"
);

Limitation: the hosted Stream Deck window appears to ignore [width], [height], resizable, maximize, and fullscreen flags.

Use [window.resizeTo()] from inside the hosted page
Example:
window.resizeTo(1280, 820);
Limitation: ignored by the Stream Deck hosted QtWebEngine window.

Save window bounds in local storage and restore them
Example:

localStorage.setItem("analysisWindowBounds", JSON.stringify({
  width: 1280,
  height: 820,
  left: 40,
  top: 40
}));

Limitation: the plugin can save the preference, but it cannot reliably apply it because runtime resize/open sizing is ignored.

Open an external browser window
Limitation: this breaks the plugin-owned hosted experience, may expose local file/plugin URLs poorly, and creates a less integrated UX. It also depends on browser behavior outside Stream Deck.

Build a separate native companion app
Limitation: this is a much heavier architecture for a feature that otherwise fits naturally inside a Stream Deck plugin window. It adds installation, updating, signing, lifecycle, and support complexity.

Make the hosted page internally responsive
This helps within the fixed window and is already being done.

Limitation: responsive layout cannot solve the fixed outer window size. The content can adapt, but the user still cannot make the workspace larger or smaller.

Contribution

• I am interested in contributing