Describe your changes

An observed user behavior in Streamlit is to change some widget's input and then directly click on a button to submit the change and see the result in the web app.
When not losing the focus on the input field first, this can sometimes lead to the trigger rerun message being sent to the server before the input's change rerun update. If the trigger button's action accesses the other widget's state, the state is read before the input's change data is processed and the update is only visible upon the next rerun as reported in #10007.

This PR wraps the setTriggerValue functions in a setTimeout(setTriggerValueLogic, 0) call. When the input's value change is in JS' event loop, e.g. via an onBlur event, and the trigger value is on the event loop, e.g. via a button's onClick event, this wrapper will put the trigger value at the end of the current event loop (without any measurable delay due to timeout 0). This assumes that we usually want to process other rerun data first and the trigger value as a follow-up action of that information. Even if this assumption is not true, right now without the PR the order is random and with this we put some more deterministic behavior around the messages which should not make any situation worse.

Note that the e2e test would also fail if we use the normal execution flow and not a callback on the button. Also, the e2e test is able to trigger the bug always, whereas manually I was only able to trigger it when loading the page in Chrome's mobile device emulator as reported by the user in
#10007. My assumption is that playwright and the mobile touch on the button are fast enough to schedule the event, whereas a mouse click loses focus on the text area first before triggering the click which puts the text area's onBlur event in front of the trigger event in JS' event loop.
I believe this behavior changed in recent versions where we refactored the components to functional ones using some custom hooks to sync the new value internally and committing to the server. My assumption is that this increased the likelihood of events being scheduled later in the event loop.

GitHub Issue Link (if applicable)

Closes #10007

Testing Plan

• Unit Tests (JS and/or Python)
  • Updated existing unit tests because with the timeout they started to fail
• E2E Tests
  • Added an e2e test with the logic reported in Text area widget value not updated in session state when directly followed by button tap #10007. The test fails without the setTimeout as it mimics exactly what the user reported.

Contribution License Agreement

By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.