You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Tip
Help move this idea forward
Is your feature request related to a problem? Please describe.
Since #51092 the generated web app manifest sets
display_override: ["minimal-ui"]alongsidedisplay: "standalone".display_overridetakes precedence overdisplay, andminimal-uiincludes 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:display_overridedisplaytrue(default)["minimal-ui"]"standalone"false[""]"browser"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-uias thedefault so the behaviour requested in #49868 is unchanged for everyone who has not opted out. For
example a
theming.standalone_window.modestring:display_overridedisplayminimal-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.enabledtofalseβ this is the only supported knob and itdoes not help: it yields
display: "browser", i.e. the full browser UI, which is further from astandalone window than the default.
Patching
ThemingController.phplocally β works, but it is lost on every server or containerupdate, 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,
theming2.9.0, All-in-One on Docker, Chrome desktop PWA,theming.standalone_window.enablednot set (defaults totrue).The relevant lines in
apps/theming/lib/Controller/ThemingController.php,getManifest(), stillpresent in 34.0.2:
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
falsebranch emitsdisplay_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
scopesuch as
/index.php/apps/dashboard/. That is not the cause, and it is worth recording because itsends admins editing something that does not exist: the generated manifest has no
scopekey atall, so the scope defaults to the
start_urldirectory β the domain root β and navigating betweenapps never leaves it. The navigation UI comes from
display_override.