Changes since 25.0.0-beta5
Breaking changes
- Use virtual threads for the default service executor
Commit · Pull request · Issue
New features
-
Auto-configure a SecurityContextHolderStrategy bean
Commit · Pull requestThis is the first step towards #21401 and completes the migration from VaadinWebSecurity (now removed) to the recently introduced VaadinSecurityConfigurer in #21373. It avoids the need to manually import VaadinAwareSecurityContextHolderStrategyConfiguration by removing the class and include the strategy bean definition in SpringSecurityAutoConfiguration with an additional SmartInitializingSingleton that sets the provided strategy bean statically in SecurityContextHolder. Removing VaadinAwareSecurityContextHolderStrategyConfiguration is a minor breaking change since applications that currently import that configuration manually with @import(VaadinAwareSecurityContextHolderStrategyConfiguration.class) must remove the explicit import. Runtime functionality is not affected since applications providing their own custom strategy bean will override the auto-configured bean and the custom strategy will be picked up by the SmartInitializingSingleton to be set statically.
-
Eagerly load ExtendedClientDetails during UI initialization
Commit · Pull requestBrowser details (ExtendedClientDetails) are now automatically fetched during UI initialization and available immediately in the UI constructor, eliminating the need for asynchronous callbacks in most cases. API changes: - Page.getExtendedClientDetails(): Now always returns a non-null instance (creates placeholder with default values if not yet fetched). Browser details are automatically populated during normal UI initialization. - ExtendedClientDetails.refresh(Consumer): New method to refresh cached browser details with fresh values from the browser. Callback is invoked when refresh completes. - Page.retrieveExtendedClientDetails(ExtendedClientDetailsReceiver): Deprecated. Use getExtendedClientDetails() to access cached details, or ExtendedClientDetails.refresh() to update them. Migration guide: Before: page.retrieveExtendedClientDetails(details -> { int width = details.getScreenWidth(); }); After: ExtendedClientDetails details = page.getExtendedClientDetails(); int width = details.getScreenWidth(); // Available immediately // Or refresh if needed: details.refresh(updated -> { int width = updated.getScreenWidth(); }); Benefits: - No null checks needed when accessing browser details - Browser details available immediately in UI constructor/onAttach - Simpler synchronous API for common use cases - Full backward compatibility maintained The browser details collection function getBrowserDetailsParameters was previously defined in FlowBootstrap.js, which was loaded after the init request. This caused the function to be undefined when Flow.ts tried to collect browser details to send with the ?v-r=init request. This change moves the browser details collection logic from FlowBootstrap.js into Flow.ts as a private method collectBrowserDetails(), and registers it as window.Vaadin.Flow.getBrowserDetailsParameters in the Flow constructor. This ensures the function is available when needed during the init request, while maintaining backward compatibility for code that calls the function via the global window object. The TypeScript implementation uses ($wnd as any) casts to access window properties like screen, document, navigator, etc., since the $wnd type doesn't include all browser DOM APIs. Values are stringified before returning to match the original JavaScript implementation. Also adds integration test to verify browser details are available immediately on page load without user interaction. Browser details are now sent eagerly with the init request, but getExtendedClientDetails() could still return null before the data arrives. This changes the API to always return a non-null instance, using a placeholder with default values (screenWidth = -1, windowName = null) until actual browser details are available. For PreserveOnRefresh functionality, the code now checks if windowName is null rather than checking if the entire ExtendedClientDetails object is null. This is necessary because: - Screen dimensions are always sent with the init request - But window.name may be empty/undefined in new browser windows - This causes windowName = null even when other details are present - Different windows with windowName = null would incorrectly share cached components Changes: - Made ExtendedClientDetails constructor public (marked as internal-only) - UIInternals.getExtendedClientDetails() creates placeholder if null - Page.getExtendedClientDetails() simplified to delegate to UIInternals - Page.retrieveExtendedClientDetails() checks screenWidth == -1 - AbstractNavigationStateRenderer: Changed 3 locations to check windowName == null instead of details == null - WebComponentUI: Changed to check windowName == null This fixes PreserveOnRefreshIT.refreshInDifferentWindow_componentIsRecreated test failure where components were incorrectly preserved across different browser windows due to cache key collisions.
-
Build-frontent to propagate build info
Commit · Pull requestAdd build info propagation to build-frontend goal so it can be executed also without prepare-frontend Closes #22679
-
Signal binding for element property (#22408)
Commit · Pull request · Issuefeat: adds Element::bindProperty(String, Signal) method that establishes a binding between a signal instance and an element: element's property is updated on UI automatically whenever the signal value changes and signal value is updated whenever the attribute is changed on the client side.
Fixes
-
Stabilize reflection class implementation
Commit · Pull request -
Ensure session lock is held during node state checks in StreamRequestHandler
Commit · Pull request · IssueStreamRequestHandler.callElementResourceHandler was performing node state checks (isInert, isEnabled, isAttached, isVisible) without holding the session lock, creating a race condition where node state could change between validation and handler execution. This change moves all node state checks inside a single session lock block to ensure thread-safe access throughout the validation process. The nested lock for UploadHandler has been removed as it's now redundant. 🤖 Generated with Claude Code
-
Make ExtendedClientDetails.refresh take a serializable parameter
Commit · Pull request -
Use window name to detect presence of extended client details
Commit · Pull requestRouteScope logic behaves differently depending on whether extended client details have been fetched. Previously, the code checked whether the instance was null, but since #22719, UIInternal.getExtendedClientDetails never returns null. This change updates the logic to instead check ExtendedClientDetails.windowName, which is always sent by the Flow client once the details are available.
-
Support Theme annotation with only defaults
Commit · Pull request · IssueSupport having Theme annotation with only default values in production mode byte scanning. Previously we always fell back on Lumo so the not seen Theme annotation didn't have an impact.
-
Remove lock file if old version format
Commit · Pull request · IssueRemove the package-lock.json file if it is made with lockfileVersion 1 or 2 as else there are conflicts when using new npm version.