-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression: property synchronization events cause a value flush #15615
Comments
PR #15583 may fix this |
@MarcinVaadin Yes, I left my feedback there already. |
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615
…5722) DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615 Co-authored-by: Marco Collovati <marco@vaadin.com>
…5723) DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615 Co-authored-by: Marco Collovati <marco@vaadin.com>
…5725) DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615 Co-authored-by: Marco Collovati <marco@vaadin.com>
…5724) DOM events related to property synchronization must not flush changes to avoid wrong execution order of events on server side. For example, an 'has-input-value-changed' event may occur before the actual value of a field has been changed and a flush will trigger listeners with an old value. Fixes #15615 Co-authored-by: Marco Collovati <marco@vaadin.com>
This ticket/PR has been released with Vaadin 23.3.5. |
This ticket/PR has been released with Vaadin 23.2.15. |
This ticket/PR has been released with Vaadin 22.0.28. |
This ticket/PR has been released with Vaadin 14.9.5. |
This ticket/PR has been released with Vaadin 14.10.0.alpha1 and is also targeting the upcoming stable 14.10.0 version. |
This ticket/PR has been released with Vaadin 24.0.0.alpha10 and is also targeting the upcoming stable 24.0.0 version. |
The event order when using debouncing sends events in wrong order. This was tried to be fixed in #14035 but apparently only issues with the core TextField was fixed (or then this was again regressed in the regression fix #15615) --------- Co-authored-by: Marco Collovati <marco@vaadin.com> Co-authored-by: Mikhail Shabarov <61410877+mshabarov@users.noreply.github.com>
The event order when using debouncing sends events in wrong order. This was tried to be fixed in #14035 but apparently only issues with the core TextField was fixed (or then this was again regressed in the regression fix #15615) --------- Co-authored-by: Marco Collovati <marco@vaadin.com> Co-authored-by: Mikhail Shabarov <61410877+mshabarov@users.noreply.github.com>
… (#17516) The event order when using debouncing sends events in wrong order. This was tried to be fixed in #14035 but apparently only issues with the core TextField was fixed (or then this was again regressed in the regression fix #15615) --------- Co-authored-by: Matti Tahvonen <matti@vaadin.com> Co-authored-by: Marco Collovati <marco@vaadin.com> Co-authored-by: Mikhail Shabarov <61410877+mshabarov@users.noreply.github.com>
Description of the bug
A regression introduced in #14090
When changing the value of NumberField from "" to "1" back and forth, the validation starts behaving weirdly (see the recording). As follows from the server logs, changing the value that way sometimes causes a value flush, but the flushed value is always the previous one.
In this specific case, the reason is the
has-input-value-changed
event that results from the@Synchronize
annotation and that causes a value flush. This event is fired beforevalue-changed
so an old value is flushed.Recording
Screen.Recording.2022-12-28.at.17.04.08.mov
Expected behavior
Property synchronization events should not be treated as triggered by the user and hence should not cause a value flush.
Minimal reproducible example
Versions
The text was updated successfully, but these errors were encountered: