PWA: minimal-ui cannot be opted out of — no way to get a true standalone window (follow-up to #49868)

[!TIP]

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

---

Is your feature request related to a problem? Please describe.

Since #51092 the generated web app manifest sets display_override: ["minimal-ui"] alongside
display: "standalone". display_override takes precedence over display, and minimal-ui
includes navigation UI by definition, so an installed Nextcloud PWA always shows a URL bar.

I understand this was deliberate and #49868 makes a reasonable case for it — back and reload
buttons are genuinely useful inside Nextcloud. The problem is that it is not opt-out. Instances
that previously had a true standalone window lost it on upgrade, with no configuration to get it
back, and admins asking about the URL bar are told it is a misconfiguration on their side when in
fact no setting can change it.

The only related system config, theming.standalone_window.enabled, gives:

value	display_override	display	resulting window
true (default)	["minimal-ui"]	"standalone"	minimal-ui — URL bar shown
false	[""]	"browser"	full browser UI

Neither value produces a standalone window. Turning off a setting named standalone_window.enabled
— the obvious thing to try when you want less browser chrome — makes it worse, and the name now
describes an outcome the setting cannot produce.

Describe the solution you'd like

Make the display mode selectable rather than implied by a boolean, keeping minimal-ui as the
default so the behaviour requested in #49868 is unchanged for everyone who has not opted out. For
example a theming.standalone_window.mode string:

value	display_override	display
minimal-ui (default)	["minimal-ui"]	"standalone"
standalone	[]	"standalone"
browser	[]	"browser"

The existing boolean could keep working exactly as it does today for backwards compatibility, with
the new setting taking precedence when present.

Describe alternatives you've considered

Setting theming.standalone_window.enabled to false — this is the only supported knob and it
does not help: it yields display: "browser", i.e. the full browser UI, which is further from a
standalone window than the default.

Patching ThemingController.php locally — works, but it is lost on every server or container
update, and it puts the instance in a modified state that complicates support.

Rewriting the manifest response in a reverse proxy — disproportionate for two JSON keys, and not
available at all on All-in-One, where the web server configuration is managed by the deployment.

A per-user setting instead of a system config — arguably nicer, since the trade-off between
navigation buttons and screen space is a personal preference. I am proposing the system config only
because it matches the existing mechanism and is a much smaller change; a per-user option would
serve the use case better if the team prefers it.

Leaving it as is — acceptable for many instances, but for kiosk-style and single-purpose
deployments, and for users who install the PWA specifically to get an app-like window, the URL bar
defeats the reason for installing it.

Additional context

Environment: Nextcloud 34.0.2, theming 2.9.0, All-in-One on Docker, Chrome desktop PWA,
theming.standalone_window.enabled not set (defaults to true).

The relevant lines in apps/theming/lib/Controller/ThemingController.php, getManifest(), still
present in 34.0.2:

'display_override' => [$this->config->getSystemValueBool('theming.standalone_window.enabled', true) ? 'minimal-ui' : ''],
'display' => $this->config->getSystemValueBool('theming.standalone_window.enabled', true) ? 'standalone' : 'browser'

Manifest served by our instance, trimmed:

{
  "start_url": "https://cloud.example.org",
  "display_override": ["minimal-ui"],
  "display": "standalone"
}

Two side notes from investigating this.

The false branch emits display_override: [""]. An empty string is not a valid display mode.
Per spec unknown entries are ignored, so it is harmless in practice, but the array should be empty
or the key omitted rather than carrying an invalid value. Happy to open that separately.

The explanation commonly found online for a URL bar in a Nextcloud PWA is a restrictive scope
such as /index.php/apps/dashboard/. That is not the cause, and it is worth recording because it
sends admins editing something that does not exist: the generated manifest has no scope key at
all, so the scope defaults to the start_url directory — the domain root — and navigating between
apps never leaves it. The navigation UI comes from display_override.

Start in apps/theming/lib/Controller/ThemingController.php at getManifest(), where the existing boolean controls display_override and display. Trace how theming system values are read and how the manifest is returned. Done means a selectable mode supports minimal-ui, standalone, and browser while preserving the current default and backward compatibility.