Hackathon 25.3: MenuConfiguration.getPageHeader calls a title generator with no route parameters

[manolo]

Description

A view with @DynamicPageTitle, a generator that reads a route parameter, and a shell that binds its header to MenuConfiguration.getPageHeader(view).

The browser tab is right, because the router resolves the title with the parameters. The header is wrong, because getPageHeader calls the same generator with a PageTitleContext whose routeParameters() is empty.

Why it matters

The two titles come from one generator and disagree, and nothing suggests why. Ours reads a product slug, so a product page printed "we cannot find that product" across the top of the product it was showing.

Expected

Pass the active route parameters to the generator, the way the router does.

Workaround

Fall back to the parameter in UI.getCurrent().getInternals().getActiveViewLocation() when the context has none, and delete that the day the context is complete.

Reproduce

08-pagetitlegenerator-bean.zip carries it: a product/:slug route with @DynamicPageTitle, a generator that reads the slug, and a Shell whose navbar prints MenuConfiguration.getPageHeader(getContent()) after every navigation.

mvn spring-boot:run, then open http://localhost:8098/product/sourdough:

Where	What it says
Browser tab	Product sourdough
Navbar header	We cannot find that product

One generator, one page, two answers. The second one is the generator's fallback for a slug it did not receive.

That project also carries a second report, a PageTitleGenerator annotated @Component becoming the whole application's generator. The two are independent: this one shows on the product route, that one on /.

Getting the project

08-pagetitlegenerator-bean.zip, 4 KB, sources only. Unzip it and:

mvn spring-boot:run

Found on 25.3.0-beta1.

[totally-not-ai]

Analysis

Real bug, and the diagnosis in the report is exactly right: the browser tab title and MenuConfiguration.getPageHeader(content) go through two different code paths, and only one of them knows the route parameters.

Tab title — AbstractNavigationStateRenderer.updatePageTitle() resolves it with the parameters of the navigation that is happening:

navigationEvent.getSource().resolvePageTitle(targetClass, parameters, queryParameters)

Header — MenuConfiguration.getPageHeader(Component) (flow-server/.../server/menu/MenuConfiguration.java:105) ends in:

return Optional.of(MenuRegistry.getTitle(content.getClass()));

and MenuRegistry.getTitle(Class) is documented as the no parameters variant: it delegates to getTitle(target, RouteParameters.empty()). So a PageTitleGenerator declared with @DynamicPageTitle is invoked with a PageTitleContext whose routeParameters() (and queryParameters()) are empty, and the generator falls into its "unknown slug" branch. The HasDynamicTitle branch just above it is unaffected, which is why this only shows with @DynamicPageTitle on a parameterized route.

Note that the empty parameters are correct for the other callers of MenuRegistry.getTitle(Class) — menu entries and AvailableViewInfo titles are resolved for routes that are not being shown. The caller that is wrong is the one that resolves the title of the view that is being shown, where the parameters are available.

Root cause

getPageHeader(Component) never looks at the active location, even though the parameters can be derived from it. The UI already knows the location: UIInternals.getActiveViewLocation() is set in showRouteTarget() before the chain is assembled, and the registry turns a path into route parameters with RouteRegistry.getNavigationRouteTarget(path) — the same lookup DefaultRouteResolver and RouteUtil.getRouteParent() use.

Proposed fix

In getPageHeader(Component), resolve the active route parameters and hand them to the generator, so header and tab title come from the same context:

1. take ui.getInternals().getActiveViewLocation();
2. resolve registry.getNavigationRouteTarget(location.getPath()), and use its getRouteParameters() only if the resolved route target class equals the content class — the content passed by a layout is not always the route of the active location, and foreign parameters would be worse than none;
3. pass the location's getQueryParameters() as well, since the router hands those to the generator too (new internal overload MenuRegistry.getTitle(Class, RouteParameters, QueryParameters); the existing two overloads keep their behavior for menus and breadcrumbs).

The parameterless MenuConfiguration.getPageHeader() overload still resolves from the menu items and therefore still cannot serve a route with mandatory parameters — that limitation is already documented on the method and is out of scope here.

Alternative considered and rejected: reading routeParameters() from UI.routerStateSignal() / RouterState. The signal is only updated in handleAfterNavigationEvents(), immediately before AfterNavigationListeners run, so a layout that renders its header from showRouterLayoutContent() would read the previous navigation's parameters. getActiveViewLocation() is already correct at that point, so deriving from the location is the safer source.

This is straightforward and low-risk, so I am opening a draft PR with the fix and a unit test in MenuConfigurationTest that asserts the generator of a product/:slug route receives the slug and the query parameter, and that no parameters are handed over when the content is not the route of the active location.

The second report carried by the same project (a PageTitleGenerator annotated @Component becoming the application-wide default, via SpringInstantiator.getPageTitleGenerator()) is independent and not touched here.