fix(desktop): default window title to app name instead of laufey_webview#35541
Conversation
A desktop app window that isn't given an explicit title showed the
backend's internal default ("laufey_webview") instead of the configured
`desktop.app.name`. Default the title to the app name (baked into the
compiled binary at compile time) so an untitled window shows e.g.
"MyApp".
The initial window is titled at creation, and the `BrowserWindow`
constructor applies the same default to any further untitled windows via
`DesktopAppName` in op state. An explicit `title` option, or a page that
sets `document.title`, still overrides it.
bartlomieju
left a comment
bartlomieju
left a comment
There was a problem hiding this comment.
Looks correct and well-scoped — explicit-title precedence is preserved and DesktopAppName is in op state before any JS runs. Two non-blocking nits below.
Also, no automated test here: desktop window titles are GUI/laufey-bound and hard to exercise in CI, so I don’t think a test is required, but a one-line note in the PR acknowledging that would be good.
| state.put(denort::desktop::InitialWindowId(std::sync::Mutex::new( | ||
| Some(window_id), | ||
| ))); | ||
| if let Some(name) = app_name { |
There was a problem hiding this comment.
nit: the initial-window path above filters empty (.filter(|n| !n.is_empty())), but this state.put stores DesktopAppName even for an empty string. Harmless because the BrowserWindow constructor re-checks !name.0.is_empty(), but filtering here too keeps the two paths symmetric, e.g. if let Some(name) = app_name.filter(|n| !n.is_empty()).
There was a problem hiding this comment.
Done in 7a621fb — filtering the empty string here too keeps the two paths symmetric.
Keep the op-state path symmetric with the initial-window path, which already filters empty names. The BrowserWindow constructor still re-checks for an empty name.
1 participant
Fixes #35501.
A desktop app window that the app doesn't explicitly title showed the
backend's internal default,
laufey_webview, rather than the configureddesktop.app.namefromdeno.json. This was visible on the docs "Hellodesktop" example, where the window title bar read
laufey_webview.The app name is already baked into the compiled binary at compile time
(from
desktop.app.name, falling back to the output file name). Thischange uses it as the default window title: the initial window is titled
at creation, and the
BrowserWindowconstructor applies the same defaultto any further untitled windows via a new
DesktopAppNamevalue in opstate.
An explicit
titleoption onnew BrowserWindow({ title })still takesprecedence, and a page that sets
document.titlestill overrides thetitle at the OS level, so this only changes the previously-empty default.
No automated test is included: desktop window titles are GUI/laufey-bound
and not exercisable in CI. Verified manually against the docs "Hello
desktop" example.