@d.kremnev
Hi Dmitriy
Thank you for the feedback and support. In the description of the textChangeEventMode EAGER bug with trimmed spaces post, I understood the statement
try to enter a space at the end of the line in the text field in the edit screen
as only considering a space(s) that was removed from the end of the line when the input had completed and not during the input itself. Since I did not have this behavior before, for reasons I cannot explain now, I had assumed that the resolution of textChangeEventMode EAGER bug with trimmed spaces was actually a workaround.
As you suggested, I tried setting trim=false and I could enter my text, however, this does not work for all use cases (see below).
In my opinion it is only logical to trim a leading or training space(s) from the input text after the input has completed, either when the user enters a <return> or <enter> key or by navigating to another component, thereby moving the input focus to another object.
Using the EAGER setting, I have the possibility to immediately remove a space, or any other character for that matter, so it does not make sense to me that the trimming is done before the user has completed their input. In my opinion, the EAGER setting should have no affect on the trim functionality. Furthermore, if EAGER is set and I set trim=false, so that the user can enter spaces between words, and the user adds an extra space(s) at the beginning or end of his input, I will have to trim that myself. That does not make sense to me.
Can you please think through the situations I have just described and give me some more feedback.
Thanks in advance.
Best regards
Chris