The browser tab is named after the workspace, not the host

Fixkamo-internal
Ya
27 Agosti 2026, 16:56 UTC
Mwandishi
kamo
Ahadi ya
06921b4

Enter Wienerschnitzel or Wendy's and the tab read "KamoCRM", while nothing inside the workspace said KamoCRM anywhere. ABC Mortgage was correct, which made it look like a per-organization fault. It was a per-HOST one: ABC Mortgage is reached on a host of its own, so the server resolved it. The other two are served from the shared platform host, where resolving by hostname answers "the platform". My regression, from removing `?org=` from the URL. The tab's branding was moved onto the session and the tab's NAME was not — it still came from the server render, which now has nothing per-tab to resolve. Worse, that name was preferred over the organization's own config.json, which is read from the tab's theme folder and so names the right tenant by construction. Three parts, because the first alone does not hold: - The layout supplies orgTitle only when the render actually resolved the organization — the same gate orgSlug already had, which I simply failed to apply here. Otherwise config.siteNameShort wins, and it is right. - The loader re-asserts on pathname change. Next re-applies generateMetadata's title after every client-side navigation, so a one-time correction is undone by the next link the member clicks. - The name is remembered per tab and applied by the pre-paint script beside the stylesheet, so a load does not show the server's answer first and swap. generateMetadata is left resolving by host. It is right for a tenant with its own host and it is the only thing a document request can do; the point is that its answer is no longer treated as authoritative when it plainly is not. Full gate: twelve guards and 3617 tests.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei