Describe the bug
Under the Aura theme, the ChatAssistant FAB is not visible when the component is placed inside AppLayout (e.g. addToNavbar(chatAssistant)). The FAB — which should be pinned to the bottom-right corner of the viewport — instead renders at the top, positioned relative to the navbar, and is clipped/hidden. The same code works correctly under Lumo.
Root cause: the FAB wrapper uses position: fixed and is positioned via right/bottom offsets relative to the viewport. This assumes position: fixed resolves against the viewport. Aura's app-layout stylesheet applies backdrop-filter: blur(20px) to the navbar part (@vaadin/aura/src/components/app-layout.css):
vaadin-app-layout::part(navbar) {
backdrop-filter: blur(20px);
}Per the CSS spec, a non-none backdrop-filter (like transform, filter, perspective, will-change, contain) makes that element the containing block for position: fixed descendants. So bottom: 25px is measured from the navbar's bottom edge (a thin strip at the top of the screen) instead of the viewport, pushing the FAB off-screen. Lumo's navbar has no such property, which is why it only reproduces under Aura.
This is broader than the navbar: the FAB will be trapped inside any ancestor that establishes a containing block (transformed/filtered/contained containers, animated panels, etc.). A CSS-only fix is not possible — a fixed descendant cannot escape an ancestor's containing block.
Expected behavior
The FAB should be pinned to the configured viewport corner regardless of theme or where the component is attached in the DOM (including inside an AppLayout navbar under Aura).
Minimal reproducible example
- Vaadin 25 app using the Aura theme.
- In an
AppLayout-based main layout, add the assistant to the navbar:
ChatAssistant<Message> chatAssistant = new ChatAssistant<>(true);
addToNavbar(chatAssistant);
- Run the app: the FAB is not visible in the bottom-right corner. Inspecting the DOM shows the FAB positioned relative to the navbar, at the top, hidden.
- Switch the app to Lumo: the FAB appears correctly in the corner.
Workaround
Because AppLayout only accepts navbar/drawer/content slots, wrap the routed views in a plain <div> (a RouterLayout, e.g. ChatAssistantLayout) and add the FAB there. That wrapper's ancestor chain (::part(content) under Aura) creates no containing block, so position: fixed reaches the viewport again. This is a user-side mitigation, not a real fix.
Why this should be fixed in the add-on
Relying on position: fixed resolving against the viewport is brittle: it silently breaks whenever any ancestor establishes a containing block, which modern themes (Aura) and common layouts do. The robust fix is for the add-on to portal the FAB wrapper (and the popover target) to a viewport-level / overlay container — the same approach Vaadin overlays use — so the FAB is immune to ancestor containing blocks and works regardless of where it is attached (including an AppLayout navbar) across all themes. Care needed: attach/detach cleanup and preserving stacking order / z-index.
Add-on Version
5.0.1
Vaadin Version
25.x (Aura theme)
Additional information
Reproduced with the Vaadin 25 starter. Only occurs under Aura; Lumo is unaffected.
Describe the bug
Under the Aura theme, the ChatAssistant FAB is not visible when the component is placed inside
AppLayout(e.g.addToNavbar(chatAssistant)). The FAB — which should be pinned to the bottom-right corner of the viewport — instead renders at the top, positioned relative to the navbar, and is clipped/hidden. The same code works correctly under Lumo.Root cause: the FAB wrapper uses
position: fixedand is positioned viaright/bottomoffsets relative to the viewport. This assumesposition: fixedresolves against the viewport. Aura's app-layout stylesheet appliesbackdrop-filter: blur(20px)to the navbar part (@vaadin/aura/src/components/app-layout.css):Per the CSS spec, a non-
nonebackdrop-filter(liketransform,filter,perspective,will-change,contain) makes that element the containing block forposition: fixeddescendants. Sobottom: 25pxis measured from the navbar's bottom edge (a thin strip at the top of the screen) instead of the viewport, pushing the FAB off-screen. Lumo's navbar has no such property, which is why it only reproduces under Aura.This is broader than the navbar: the FAB will be trapped inside any ancestor that establishes a containing block (transformed/filtered/contained containers, animated panels, etc.). A CSS-only fix is not possible — a fixed descendant cannot escape an ancestor's containing block.
Expected behavior
The FAB should be pinned to the configured viewport corner regardless of theme or where the component is attached in the DOM (including inside an
AppLayoutnavbar under Aura).Minimal reproducible example
AppLayout-based main layout, add the assistant to the navbar:Workaround
Because
AppLayoutonly accepts navbar/drawer/content slots, wrap the routed views in a plain<div>(aRouterLayout, e.g.ChatAssistantLayout) and add the FAB there. That wrapper's ancestor chain (::part(content)under Aura) creates no containing block, soposition: fixedreaches the viewport again. This is a user-side mitigation, not a real fix.Why this should be fixed in the add-on
Relying on
position: fixedresolving against the viewport is brittle: it silently breaks whenever any ancestor establishes a containing block, which modern themes (Aura) and common layouts do. The robust fix is for the add-on to portal the FAB wrapper (and the popover target) to a viewport-level / overlay container — the same approach Vaadin overlays use — so the FAB is immune to ancestor containing blocks and works regardless of where it is attached (including anAppLayoutnavbar) across all themes. Care needed: attach/detach cleanup and preserving stacking order /z-index.Add-on Version
5.0.1
Vaadin Version
25.x (Aura theme)
Additional information
Reproduced with the Vaadin 25 starter. Only occurs under Aura; Lumo is unaffected.