Make throttling in the dirty_submit form check smarter
What does this MR do?
Makes the throttling in the dirty_submit
feature smarter. dirty_submit
is documented here: https://docs.gitlab.com/ee/development/new_fe_guide/modules/dirty_submit.html.
This will fix #61928 (closed).
Current behavior
In its current form, the dirty_submit
function throttles its checks for changes to the form. This is to avoid performance problems since the function listens to the change
and input
events (the latter is called on every keystroke in a text field).
However, because its checks are throttled, its possible that the throttling will cause an update to be ignored when receiving multiple, quick updates from different form elements. This causes the behavior demonstrated in #61928 (closed).
New behavior
Instead of throttling the change checking function per form, the dirty_submit
function now throttles its checks per form element. This means that the function still retains its performance benefits (lots of calls on the same element will still be throttled), but changing the value a particular form element won't affect any other element. Essentially, each element has its own throttle that won't interfere with the throttling of another element.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation created/updated or follow-up review issue created -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Performance and testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Closes #61928 (closed)