fix: sync editor value to server when same value is typed again#9568
Merged
Conversation
sissbruecker
marked this pull request as draft
June 19, 2026 11:43
sissbruecker
commented
Jun 22, 2026
|
|
||
| window.Vaadin.Flow.gridProConnector = { | ||
| selectAll: (editor, itemKey, grid) => { | ||
| handleCustomEditorValueUpdate: (editor, itemKey, grid) => { |
Contributor
Author
There was a problem hiding this comment.
Kept this refactoring as it includes other logic than just selecting the value.
sissbruecker
marked this pull request as ready for review
June 22, 2026 08:56
vursen
reviewed
Jun 22, 2026
|
vursen
approved these changes
Jun 22, 2026
sissbruecker
added a commit
that referenced
this pull request
Jun 22, 2026
… (CP: 25.2) (#9572) This PR cherry-picks changes from the original PR #9568 to branch 25.2. --- #### Original PR description > ## Description > > Since a recent change, Firefox treats input fields that have the same value on blur as they had on focus as unchanged, even if the value was changed programmatically in between. This is problematic for custom editors in GridPro, where the value is set programmatically from the server after the client-side component has already focused the editor. If, after starting editing, a user types exactly the same value that the input had before the server updated the editor value, no change event is fired and the editor value is never synced to the server where it would be used to update the item data: > - First edit: > - User edits cell, types "foo", commits > - "foo" is different from the value the editor had before focus (empty value), property is synced to the server > - `item-property-change` fires, server detects change in the editor's value, item is updated on server > - Second edit (same column, different cell) > - User starts editing, web component focuses editor component immediately > - Initially the client-side value is still "foo", the server only updates the editor's value once it receives the `cell-edit-started` event, which eventually results in a client-side update of the editor value, let's say to "bar" > - User types "foo" again, commits > - "foo" is not different from the value the editor had before focusing it, no change event is fired for the editor, it's value is not synced back to the server > - `item-property-change` fires, server does not detect a change in the editor's value, no item update > > This change addresses the issue by always firing a synthetic change event whenever an input element loses focus. The fix is scoped only Firefox, and only to custom editors. For built-in editors no such fix is needed as the edited value is applied by the web component before focusing. The change is not covered by tests, as the issue only manifests in Firefox whereas tests only run in Chrome. > > Fixes #9437 > > ## Type of change > > - Bugfix > Co-authored-by: Sascha Ißbrücker <sissbruecker@vaadin.com>
sissbruecker
added a commit
that referenced
this pull request
Jun 22, 2026
… (CP: 25.1) (#9573) This PR cherry-picks changes from the original PR #9568 to branch 25.1. --- #### Original PR description > ## Description > > Since a recent change, Firefox treats input fields that have the same value on blur as they had on focus as unchanged, even if the value was changed programmatically in between. This is problematic for custom editors in GridPro, where the value is set programmatically from the server after the client-side component has already focused the editor. If, after starting editing, a user types exactly the same value that the input had before the server updated the editor value, no change event is fired and the editor value is never synced to the server where it would be used to update the item data: > - First edit: > - User edits cell, types "foo", commits > - "foo" is different from the value the editor had before focus (empty value), property is synced to the server > - `item-property-change` fires, server detects change in the editor's value, item is updated on server > - Second edit (same column, different cell) > - User starts editing, web component focuses editor component immediately > - Initially the client-side value is still "foo", the server only updates the editor's value once it receives the `cell-edit-started` event, which eventually results in a client-side update of the editor value, let's say to "bar" > - User types "foo" again, commits > - "foo" is not different from the value the editor had before focusing it, no change event is fired for the editor, it's value is not synced back to the server > - `item-property-change` fires, server does not detect a change in the editor's value, no item update > > This change addresses the issue by always firing a synthetic change event whenever an input element loses focus. The fix is scoped only Firefox, and only to custom editors. For built-in editors no such fix is needed as the edited value is applied by the web component before focusing. The change is not covered by tests, as the issue only manifests in Firefox whereas tests only run in Chrome. > > Fixes #9437 > > ## Type of change > > - Bugfix > Co-authored-by: Sascha Ißbrücker <sissbruecker@vaadin.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Since a recent change, Firefox treats input fields that have the same value on blur as they had on focus as unchanged, even if the value was changed programmatically in between. This is problematic for custom editors in GridPro, where the value is set programmatically from the server after the client-side component has already focused the editor. If, after starting editing, a user types exactly the same value that the input had before the server updated the editor value, no change event is fired and the editor value is never synced to the server where it would be used to update the item data:
item-property-changefires, server detects change in the editor's value, item is updated on servercell-edit-startedevent, which eventually results in a client-side update of the editor value, let's say to "bar"item-property-changefires, server does not detect a change in the editor's value, no item updateThis change addresses the issue by always firing a synthetic change event whenever an input element loses focus. The fix is scoped only Firefox, and only to custom editors. For built-in editors no such fix is needed as the edited value is applied by the web component before focusing. The change is not covered by tests, as the issue only manifests in Firefox whereas tests only run in Chrome.
Fixes #9437
Type of change