firstUpdated fires on blank render, breaking topbarObserver

Returning nothing on the first render means firstUpdated() is called while no DOM exists. handleFirstUpdated calls observeTopbar, which queries host.querySelector(".topbar"). Since nothing produces no DOM, it finds no element and returns early — leaving host.topbarObserver as null permanently.

When localeReady becomes true and the component re-renders with real content (including .topbar), LitElement will call updated() but not firstUpdated() again. The topbar ResizeObserver is never created, so the --topbar-height CSS variable is never set.

A straightforward fix is to call observeTopbar the first time localeReady flips to true inside updated(), e.g.:

protected updated(changed: Map<PropertyKey, unknown>) {
  if (changed.has('localeReady') && this.localeReady) {
    observeTopbar(this);
  }
  handleUpdated(this as unknown as Parameters<typeof handleUpdated>[0], changed);
}

Or alternatively, call observeTopbar directly in the Promise.all callback after setting localeReady = true.

This is a comment left during a code review.
Path: ui/src/ui/app.ts
Line: 729-731

Comment:
**`firstUpdated` fires on blank render, breaking `topbarObserver`**

Returning `nothing` on the first render means `firstUpdated()` is called while no DOM exists. `handleFirstUpdated` calls `observeTopbar`, which queries `host.querySelector(".topbar")`. Since `nothing` produces no DOM, it finds no element and returns early — leaving `host.topbarObserver` as `null` permanently.

When `localeReady` becomes `true` and the component re-renders with real content (including `.topbar`), LitElement will call `updated()` but **not** `firstUpdated()` again. The topbar `ResizeObserver` is never created, so the `--topbar-height` CSS variable is never set.

A straightforward fix is to call `observeTopbar` the first time `localeReady` flips to `true` inside `updated()`, e.g.:

```ts
protected updated(changed: Map<PropertyKey, unknown>) {
  if (changed.has('localeReady') && this.localeReady) {
    observeTopbar(this);
  }
  handleUpdated(this as unknown as Parameters<typeof handleUpdated>[0], changed);
}
```

Or alternatively, call `observeTopbar` directly in the `Promise.all` callback after setting `localeReady = true`.

How can I resolve this? If you propose a fix, please make it concise.

Race condition: concurrent setLocale calls may interleave

I18nManager is a module-level singleton instantiated at import time. Its constructor immediately calls loadLocale(), which calls setLocale(initialLocale) asynchronously. When OpenClawApp's constructor then calls i18n.setLocale(this.settings.locale), both calls can be in-flight simultaneously.

setLocale has no mutual-exclusion guard — if two calls overlap for the same locale that needs a translation download, loadLazyLocaleTranslation is called twice (wasteful but not data-corrupting). For different locales, the final value of this.locale depends on which await resolves last, not on which call was initiated last. For example: if settings.locale is "fr" but initialLocale (from navigator) is "zh-CN", the component could end up with either locale after Promise.all resolves.

Consider adding a simple "last writer wins with a generation counter" guard inside setLocale, or at minimum document that i18n.ready only reflects the startup locale — not the override applied in the OpenClawApp constructor.

This is a comment left during a code review.
Path: ui/src/ui/app.ts
Line: 119-133

Comment:
**Race condition: concurrent `setLocale` calls may interleave**

`I18nManager` is a module-level singleton instantiated at import time. Its constructor immediately calls `loadLocale()`, which calls `setLocale(initialLocale)` asynchronously. When `OpenClawApp`'s constructor then calls `i18n.setLocale(this.settings.locale)`, both calls can be in-flight simultaneously.

`setLocale` has no mutual-exclusion guard — if two calls overlap for the same locale that needs a translation download, `loadLazyLocaleTranslation` is called twice (wasteful but not data-corrupting). For **different** locales, the final value of `this.locale` depends on which `await` resolves last, not on which call was initiated last. For example: if `settings.locale` is `"fr"` but `initialLocale` (from navigator) is `"zh-CN"`, the component could end up with either locale after `Promise.all` resolves.

Consider adding a simple "last writer wins with a generation counter" guard inside `setLocale`, or at minimum document that `i18n.ready` only reflects the startup locale — not the override applied in the `OpenClawApp` constructor.

How can I resolve this? If you propose a fix, please make it concise.

Avoid blanking UI while locale chunks are still loading

Blocking render() on localeReady means the entire Control UI stays empty until i18n.ready and settingsLocale resolve; when a non-English locale chunk load is slow or stalls, users get a blank screen instead of a usable fallback UI. This is a startup availability regression introduced by this change because there is no timeout, loading state, or fallback render path while those promises are pending.

Useful? React with 👍 / 👎.

Avoid canceling startup locale load on no-op setLocale calls

setLocale() now increments localeSeq before the early-return no-op check, so a concurrent no-op call (for example the startup call in ui/src/ui/app.ts:121 when the current locale is already en) can invalidate the in-flight loadLocale() request started in the constructor. Because i18n.ready only awaits that initial loadLocale() call, it can resolve after the request is canceled rather than after the active startup locale has actually loaded, which means callers that gate first render on i18n.ready can still render in the wrong language.

Useful? React with 👍 / 👎.

Move sequence bump after no-op locale short-circuit

Incrementing localeSeq before the no-op return allows a no-op setLocale() call to cancel an in-flight locale load that should still complete. In this commit, if startup loadLocale() begins loading a saved non-English locale and a concurrent setLocale("en") returns early because the current locale is already English, the sequence mismatch aborts the startup load and leaves i18n.ready resolved with the wrong locale; I verified this by reproducing openclaw.i18n.locale=zh-CN followed by immediate setLocale("en"), which ends with getLocale() still at en.

Useful? React with 👍 / 👎.

Keep i18n.ready pending until winning locale load finishes

i18n.ready now awaits loadLocale(), but the stale-request guard can make that startup call return early when another setLocale() runs first, so ready can resolve before the active locale request completes. Fresh evidence: with openclaw.i18n.locale=zh-CN and an immediate setLocale("pt-BR"), await i18n.ready returns while getLocale() is still en. Any caller that gates first render on ready can still render in the wrong language.

Useful? React with 👍 / 👎.

Keep core ownership when registering legacy context engine

registerContextEngine() now hard-codes PUBLIC_CONTEXT_ENGINE_OWNER, but registerContextEngineForOwner() rejects non-core owners for the default context-engine id (legacy). The built-in startup path still registers legacy through registerContextEngine("legacy", ...), so that call now returns { ok: false } and leaves no default engine installed; subsequent ensureContextEnginesInitialized() + resolveContextEngine() flows can fail with Context engine "legacy" is not registered.

Useful? React with 👍 / 👎.

Register core default engine through privileged owner

registerContextEngine() now always uses the unprivileged public-sdk owner, but registerContextEngineForOwner() rejects that owner for the default context-engine slot id (legacy). The built-in bootstrap still calls registerContextEngine("legacy", ...) via registerLegacyContextEngine(), so startup silently fails to register the default engine and later resolveContextEngine() can throw Context engine "legacy" is not registered even in core-only setups.

Useful? React with 👍 / 👎.