Skip to content

Vaadin Flow Components V25.1.8

Latest
Latest

Choose a tag to compare

View all tags
@vaadin-bot vaadin-bot released this 15 Jun 07:51
25.1.8
b7b1801
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Vaadin Flow Components 25.1.8

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.1.7

Changes in vaadin-spreadsheet-flow

  • Fixes:

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

      This PR cherry-picks changes from the original PR #9303 to branch 25.1. --- #### 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

    • ⧉ Defer Spreadsheet.selectCellRange until sheet widget layout is ready (#9381) (CP: 25.1). PR:9486

      This PR cherry-picks changes from the original PR #9381 to branch 25.1. --- > > Follow-up to #9333. When a Spreadsheet inside a closed Dialog is opened, Flow > flushes the property writes and the setSelectedCellAndRange RPC in the same > task. The api receives the call before the deferred init scheduled in > SheetWidget.resetFromModel has run — so SheetWidget.getRowHeight reads an > uninitialized definedRowHeights and throws > > > Uncaught TypeError: Cannot read properties of undefined (reading 'length') > > > That throw drops the selection and trips the *_noErrors/*_noConsoleErrors > console-log assertions. > > #9333's connector-side guard masked this by probing definedRowHeights > through the api's private GWT fields — names that only survive > -Dgwt.style=pretty (local/dev). CI compiles the GWT client with > -Dgwt.style=OBF, where those private names are renamed and api.spreadsheetWidget > is undefined. The guard itself then threw, producing the same SEVERE log and > the same ~20 spreadsheet IT failures on the cherry-pick PRs. > > > Move the layout-readiness handling into the widget that owns the operation: > > - SheetWidget.isLoaded() (package-private) — exposes the already-existing > loaded flag that flips at the end of resetFromModel's deferred command. > - SpreadsheetWidget.selectCellRange — if !sheetWidget.isLoaded(), store the > latest args and Scheduler.scheduleDeferred(this::applyPendingSelectCellRange). > The deferred re-checks, applies, or re-schedules. Latest-wins (rapid successive > calls collapse to the final selection). Bounded at 100 hops as a safety net; > in the typical case the layout init has already been scheduled before us, so > GWT's FIFO scheduler resolves us in 0–1 hops. > - vaadin-spreadsheet.js — setSelectedCellAndRange goes back to a one-liner > (this._flush(); this.api.setSelectedCellAndRange(...args)). No try/catch, > no pending state, no constants. > > Only selectCellRange is deferred — it's the only RPC that touches row/column > metrics. Other RPCs (cellsUpdated, popup ops, etc.) don't need this and > didn't fail in the original CI runs. > > > Reproduce locally by compiling the client with -Dgwt.style=OBF (matching CI) > and running the merged ITs in production mode: > > > mvn clean install -DskipTests -Dgwt.style=OBF \ > -pl vaadin-spreadsheet-flow-parent/vaadin-spreadsheet-flow-client,vaadin-spreadsheet-flow-parent/vaadin-spreadsheet-flow > node scripts/mergeITs.js spreadsheet > mvn verify -Drun-it -pl integration-tests -Dvaadin.productionMode=true \ > -Dit.test='NavigationIT,SpreadsheetDialogIT' -DskipUnitTests > > > - With this PR → NavigationIT 26/0, SpreadsheetDialogIT 1/0. > - Reverting only the GWT-side change → SpreadsheetDialogIT fails with the > underlying Cannot read properties of undefined (reading 'length') in > FlowClient-…js — the actual definedRowHeights NPE. > > Follow-up to #9333. > > --- > > 🤖 Generated with Claude Code

    • ⧉ Hide already-filtered values from other spreadsheet column filters (#9386). PR:9464

      This PR cherry-picks changes from the original PR #9386 to branch 25.1. --- #### Original PR description > ## Description > > In a SpreadsheetFilterTable with filters on multiple columns, opening any column's filter dropdown showed values from rows already hidden by other columns as unchecked, suggesting they were filtered by this column. Re-checking them did nothing because another column still hid the row. > > Applying a second filter then implicitly added those already-hidden rows to the second column's filteredRows, so clearing the first filter did not bring the rows back — the second column now also filtered them. > > Root cause: ItemFilter read spreadsheet.isRowHidden(r) for both building option lists and deciding which rows belong in its own filteredRows. That property reflects the union of all column filters, so each filter could not tell its own work from a sibling's. > > Each ItemFilter now operates only on its own filteredRows. The dropdown option list omits values whose rows are all hidden by other columns via a new SpreadsheetFilterTable.getRowsHiddenByOtherFilters(self) helper. clearAllFilters does a second pass to refresh option lists so cleared siblings are reflected immediately. > > Fixes #9329 > > ## Reproduction > > java > @Route("spreadsheet-filter-cross-column") > public class SpreadsheetFilterCrossColumnPage extends VerticalLayout { > > public SpreadsheetFilterCrossColumnPage() { > Spreadsheet spreadsheet = new Spreadsheet(); > spreadsheet.setTheme(SpreadsheetTheme.LUMO); > spreadsheet.setHeight("400px"); > > spreadsheet.createCell(0, 0, "Column A"); > spreadsheet.createCell(0, 1, "Column B"); > spreadsheet.createCell(0, 2, "Column C"); > > spreadsheet.createCell(1, 0, "Alpha"); > spreadsheet.createCell(1, 1, "Foo"); > spreadsheet.createCell(1, 2, "Alice"); > > spreadsheet.createCell(2, 0, "Beta"); > spreadsheet.createCell(2, 1, "Bar"); > spreadsheet.createCell(2, 2, "Bob"); > > spreadsheet.createCell(3, 0, "Gamma"); > spreadsheet.createCell(3, 1, "Baz"); > spreadsheet.createCell(3, 2, "Carol"); > > CellRangeAddress range = new CellRangeAddress(0, 3, 0, 2); > SpreadsheetFilterTable table = new SpreadsheetFilterTable(spreadsheet, > range); > spreadsheet.registerTable(table); > spreadsheet.refreshAllCellValues(); > > add(spreadsheet); > } > } > > > | Column A | Column B | Column C | > | -------- | -------- | -------- | > | Alpha | Foo | Alice | > | Beta | Bar | Bob | > | Gamma | Baz | Carol | > > Steps to reproduce: > > - Filter Beta in column A. > - Open the filter dropdown in column B → Bar shows up unchecked (before the fix), suggesting column B filtered it. > - Filter Foo in column B. > - Re-check Beta in column A → the row does not reappear (before the fix), because column B now also filters it. > > 🤖 Generated with Claude Code >

Changes in vaadin-upload-flow

  • Fixes:

    • ⧉ Avoid serializing full File instance for determining uploading state (#9444) (CP: 25.1). PR:9450

      This PR cherry-picks changes from the original PR #9444 to branch 25.1. --- > ## Description > > The Flow Upload component currently listens to several web component events to determine whether the component is still processing any upload or not. To facilitate that it sends fully serialized instances of all JS File objects to the server in order to access the uploading property of each. Serializing the full File object can lead to circular serialization issues as reported in #9434. > > This changes the respective event listeners to determine the uploading state on the client via a JS expression and then only sends a single boolean with the event, rather than the full File object. This avoids serializing File objects completely and also reduces the payload of the event. > > Fixes #9434 > > ## Type of change > > - Bugfix

Compatibility

  • This release use Web Components listed in Vaadin Platform 25.1.8
  • Tested with Vaadin Flow version 25.1.11
Assets 2
Loading