[Security Solution] Fix cursor jumping to end of text area when editing Rule Action Message

[spong]

Summary

Resolves: #149885

For additional details, please see #141811 (comment) and #142217.

As mentioned in #142217, this issue is the result of managing stale events and timings (renderings + field updates) between the Detections RuleActionsField component, validation within the hooks-form lib, and field updates coming from the trigger_actions_ui components.

Note: this behavior is explicit to the Edit Rule flow (ActionsStepRule form), and not the Bulk Actions flyout (RuleActionsFormData form) as events flow as intended in the latter, presumably because of all the nested components and use of useFormData within the Edit Rule flow (see form libs docs).

The fix here is a modification of the fix provided in #141811 with setTimeout, but instead of always pushing the params update to be within a setTimeout, it now only does it when initially loading Actions with empty Params. Since this fix also has the unintended side-effect of flickering the validation error callout when first adding an action, validation is now throttled to 100ms intervals, which also helps with extraneous re-renders.

Before initial fix (with cursor issue) / Before throttle fix w/ flashing error callout:

After:

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[spong]

Lodash throttle potentially could've been used here instead, however it doesn't work with async functions, so just deferred to leveraging actual cancellable async validation via the hooks form lib itself (docs).

[maximpn]

@spong the changes look good, thank you for fixing such and annoying bug 👍

I have some general concerns. It was time consuming to follow to the root cause. For me as a library consumer I expect straightforward usage but having things like an isInitializingAction flag or setTimeout with zero delay looks like a workaround for some problems. I see that some Kibana teams use react-hook-form which looks quite similar to Kibana's form lib. I'm wonder if we can achieve the same functionality with react-hook-form but reduce the codebase size and avoid problems we got here and need to overcome.

[maximpn]

nit: it should be possible to use ValidationCancelablePromise here for type declaration

[spong]

Thank you! 👍 Was also able to use ValidationResponsePromise<ERROR_CODE> above on #36 and ValidationResponsePromise on #72 as well 🙂

[maximpn]

Sorry, I don't wanna be naggy here but rather wanna have clear understanding on what's going on under the hood. I didn't go into deep implementation details of form lib but I have an impression that it's rather debouncing than throttling if look at the code. If validations happens too fast then isCancelled flag is set to true before evaluation of the if condition. This means the validation will be performed only after timeout and new validation requests don't come up which is basically debouncing.

[spong]

Oh you're not being naggy at all -- I appreciate the thoroughness @maximpn as I may've gotten a little myopic after trying to hunt down a fix here. 😅

This is indeed behaving as a debounce, nice catch! I'll update the function name and jsdoc to reflect that it's a debounce and clearly mention that we're essentially leveraging the async validation cancellation behavior from the hook_form_lib as such.

[spong]

@spong the changes look good, thank you for fixing such and annoying bug 👍

I have some general concerns. It was time consuming to follow to the root cause. For me as a library consumer I expect straightforward usage but having things like an isInitializingAction flag or setTimeout with zero delay looks like a workaround for some problems. I see that some Kibana teams use react-hook-form which looks quite similar to Kibana's form lib. I'm wonder if we can achieve the same functionality with react-hook-form but reduce the codebase size and avoid problems we got here and need to overcome.

Absolutely, I 100% agree @maximpn. Having not been in this section of the codebase for some time it was hard to grok the control flow between the security code, trigger_actions_ui, and our (outdated) usage of the hook_form_lib. I was hoping for a more surgical root cause fix of #142217, but I wasn't able to find one without requiring a bit more refactoring.

As such, I went ahead and opened #151202 to capture this tech debt/refactoring effort, so we can re-evaluate our implementation (control flow, re-use of trigger_actions components, form libs, etc) as part of this 🙂

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: fd35444

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	13.9MB	13.9MB	+856.0B

History

• 💚 Build #108369 succeeded 77bf851
• 💚 Build #107772 succeeded a5d77c4
• 💚 Build #107142 succeeded 1775e75

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @spong

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.7

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation