Vaadin Flow Components V25.0.13

Vaadin Flow Components 25.0.13

This is a release of the Java integration for Vaadin Components to be used from the Java server side with Vaadin Flow.

Changes in Flow Components from 25.0.12

Changes in vaadin-charts-flow

• New Features:

  • ⧉ Validate navigation-related URL schemes (#9447) (CP: 25.0). PR:9724

    This PR cherry-picks changes from the original PR #9708 to branch 25.0. --- > Mirror the Flow URL-scheme validation (vaadin/flow#24539) for the navigation, action and link sinks in flow-components. A javascript: (or other non-allow-listed) scheme on a value that the browser later treats as a link, form action or script source is a familiar XSS shape; rejecting it at the setter closes that path while leaving an explicit escape hatch for trusted, hard-coded URLs. > > Validating setters added across the affected components, each with a matching setUnsafe* variant that bypasses validation: > > - SideNavItem.setPath / BreadcrumbsItem.setPath — navigation link. > - Credits.setHref — clickable Highcharts credits link. > - AbstractLogin.setAction — the form action attribute the browser POSTs to on submit. > - Exporting.setUrl — Highcharts posts SVG to this URL as a form action for export fallback. > - Exporting.setLibURL — concatenated into <script src="…"> to load offline-export dependencies at runtime. > > SideNavItem constructor that takes a String path validates transitively via setPath; their Javadoc now documents @throws IllegalArgumentException and explicit constructor tests cover the behaviour. > > Safe schemes are configured through the safeUrlSchemes property and default to http, https, mailto, tel, ftp. > > Image, icon, SVG, Avatar, map tile and chart-resource URLs are intentionally not validated: javascript: cannot execute in <img src> / SVG <image> elements, and data: URLs are a legitimate, common use there. > > LoginFormTest and LoginOverlayTest already mock LoggerFactory to capture the existing "action attribute together with login listeners" warning. After merging Flow main, those tests started NPE-ing: Flow's UrlUtil.isSafeUrl debug-logs a fallback notice, going through LoggerFactory.getLogger(UrlUtil.class) which returned null inside the broad mock. The mock now uses Mockito.CALLS_REAL_METHODS so unrelated lookups fall through to the real factory; the explicit LoginForm/Overlay.class stubs still take precedence. > > Part of vaadin/flow#24539

Changes in vaadin-login-flow

• New Features:

  • ⧉ Validate navigation-related URL schemes (#9447) (CP: 25.0). PR:9724

    This PR cherry-picks changes from the original PR #9708 to branch 25.0. --- > Mirror the Flow URL-scheme validation (vaadin/flow#24539) for the navigation, action and link sinks in flow-components. A javascript: (or other non-allow-listed) scheme on a value that the browser later treats as a link, form action or script source is a familiar XSS shape; rejecting it at the setter closes that path while leaving an explicit escape hatch for trusted, hard-coded URLs. > > Validating setters added across the affected components, each with a matching setUnsafe* variant that bypasses validation: > > - SideNavItem.setPath / BreadcrumbsItem.setPath — navigation link. > - Credits.setHref — clickable Highcharts credits link. > - AbstractLogin.setAction — the form action attribute the browser POSTs to on submit. > - Exporting.setUrl — Highcharts posts SVG to this URL as a form action for export fallback. > - Exporting.setLibURL — concatenated into <script src="…"> to load offline-export dependencies at runtime. > > SideNavItem constructor that takes a String path validates transitively via setPath; their Javadoc now documents @throws IllegalArgumentException and explicit constructor tests cover the behaviour. > > Safe schemes are configured through the safeUrlSchemes property and default to http, https, mailto, tel, ftp. > > Image, icon, SVG, Avatar, map tile and chart-resource URLs are intentionally not validated: javascript: cannot execute in <img src> / SVG <image> elements, and data: URLs are a legitimate, common use there. > > LoginFormTest and LoginOverlayTest already mock LoggerFactory to capture the existing "action attribute together with login listeners" warning. After merging Flow main, those tests started NPE-ing: Flow's UrlUtil.isSafeUrl debug-logs a fallback notice, going through LoggerFactory.getLogger(UrlUtil.class) which returned null inside the broad mock. The mock now uses Mockito.CALLS_REAL_METHODS so unrelated lookups fall through to the real factory; the explicit LoginForm/Overlay.class stubs still take precedence. > > Part of vaadin/flow#24539

Changes in vaadin-side-nav-flow

• New Features:

  • ⧉ Validate navigation-related URL schemes (#9447) (CP: 25.0). PR:9724

    This PR cherry-picks changes from the original PR #9708 to branch 25.0. --- > Mirror the Flow URL-scheme validation (vaadin/flow#24539) for the navigation, action and link sinks in flow-components. A javascript: (or other non-allow-listed) scheme on a value that the browser later treats as a link, form action or script source is a familiar XSS shape; rejecting it at the setter closes that path while leaving an explicit escape hatch for trusted, hard-coded URLs. > > Validating setters added across the affected components, each with a matching setUnsafe* variant that bypasses validation: > > - SideNavItem.setPath / BreadcrumbsItem.setPath — navigation link. > - Credits.setHref — clickable Highcharts credits link. > - AbstractLogin.setAction — the form action attribute the browser POSTs to on submit. > - Exporting.setUrl — Highcharts posts SVG to this URL as a form action for export fallback. > - Exporting.setLibURL — concatenated into <script src="…"> to load offline-export dependencies at runtime. > > SideNavItem constructor that takes a String path validates transitively via setPath; their Javadoc now documents @throws IllegalArgumentException and explicit constructor tests cover the behaviour. > > Safe schemes are configured through the safeUrlSchemes property and default to http, https, mailto, tel, ftp. > > Image, icon, SVG, Avatar, map tile and chart-resource URLs are intentionally not validated: javascript: cannot execute in <img src> / SVG <image> elements, and data: URLs are a legitimate, common use there. > > LoginFormTest and LoginOverlayTest already mock LoggerFactory to capture the existing "action attribute together with login listeners" warning. After merging Flow main, those tests started NPE-ing: Flow's UrlUtil.isSafeUrl debug-logs a fallback notice, going through LoggerFactory.getLogger(UrlUtil.class) which returned null inside the broad mock. The mock now uses Mockito.CALLS_REAL_METHODS so unrelated lookups fall through to the real factory; the explicit LoginForm/Overlay.class stubs still take precedence. > > Part of vaadin/flow#24539

Changes in vaadin-spreadsheet-flow

• Fixes:

  • ⧉ Style spreadsheet overlays when nested in a shadow root (#9713) (CP: 25.0). PR:9717

    This PR cherry-picks changes from the original PR #9713 to branch 25.0. --- #### Original PR description > Since #9303, spreadsheet overlays (context menu, popup-button filters, cell comments, tooltips) live in a #spreadsheet-overlays container in the component's light DOM, styled by a global <style> in document.head. When <vaadin-spreadsheet> is nested in another element's shadow root — for example embedded as a web component, as in the docs filtering example — the container ends up inside that shadow tree, which the document-level stylesheet cannot cross, so the overlays render unstyled. > > To reproduce: open the docs "spreadsheet filtering" example (the spreadsheet is embedded as a web component) and open a column filter — the popup shows with no rounded corners, background, or shadow. > > On attach, also adopt the overlay stylesheet onto the container's own root (this._overlays.getRootNode()) when that root is a ShadowRoot, so the scoped #spreadsheet-overlays … rules apply inside the shadow tree. Top-level usage is unchanged: the root is the document, already covered by the existing document.head stylesheet. > > Follow-up to #9303 > > --- > > 🤖 Generated with Claude Code > > https://claude.ai/code/session_01QjNdPXWEUciMEXQe9hMgMt >

  • ⧉ Make spreadsheet overlays native popover, per instance (#9303) (CP: 25.0). PR:9497

    This PR cherry-picks changes from the original PR #9303 to branch 25.0. --- #### Original PR description > The spreadsheet attaches a <div id="spreadsheet-overlays"> to host its overlay widgets (context menu, tooltips, comment overlays, popup buttons). It has historically lived in <body> to escape clipping by ancestor overflow/transform rules and as a singleton shared by all spreadsheet instances on the page. Switching the overlays to native popover changes the picture: every overlay enters the top layer regardless of DOM position, so neither the body-attachment nor the singleton are load-bearing anymore. > > This PR includes the native popover changes proposed in #9270 and adds the structural changes that the popover approach enables: > > - the container moves into the <vaadin-spreadsheet> light DOM, projected into the shadow root via a new overlays slot, with one container per instance; > - the reference is threaded from JS into the GWT widget chain instead of being looked up by id; > - SpreadsheetConnector — not ApplicationConnection — now owns the SpreadsheetContextMenu. > > Tooltips and the cell-comment overlay are created in SheetWidget's constructor (before the host is known), so the container is wired in via a setter rather than a constructor argument. > > A side benefit: spreadsheet overlays inside a modal Dialog are interactive again. The modal sets body { pointer-events: none } to disable everything outside the dialog overlay; with the container now inside the dialog's slotted content, the overlays inherit pointer-events: auto from the dialog's overlay part instead of pointer-events: none from <body>. > > Intended to replace #9270. > > Related to #9270 > > --- > > 🤖 Generated with Claude Code

Compatibility

• This release use Web Components listed in Vaadin Platform 25.0.13
• Tested with Vaadin Flow version 25.0.15