# \[BUG\] TextArea clips first enter/newline after refocus

**URL:** <https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993>\
**Category:** Ignition\
**Tags:** perspective, ignition81\
**Created:** [May 7, 2025, 3:53pm UTC](https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993 "2025-05-07T15:53:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\
**Post date:** [May 7, 2025, 3:53pm UTC](https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993/1 "2025-05-07T15:53:21Z")

</div>

Version 8.1.47

Scenario:

1. Type two lines of text into a TextArea
2. Click outside the TextArea
3. Click back in the TextArea at the end of the first line, and hit ENTER
4. Click outside the TextArea or hit ENTER again--either action causes the newline created in step #3 to disappear

I have tried every combination of the `deferUpdates` and `rejectUpdatesWhileFocused` properties, but it always behaves like this. The second line of text isn't necessary, it just makes the behavior more obvious. The newline is clipped wherever you type it, so long as either the component loses focus, or the next character typed is also a newline.

A couple more observations:

- Losing focus does not cause this behavior when done via hitting TAB
- When `rejectUpdatesWhileFocused` is False, hitting ENTER twice in a row after refocus not only clips the second newline, but causes the cursor to jump to the end of the text

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [May 8, 2025, 6:33am UTC](https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993/2 "2025-05-08T06:33:26Z")

</div>

It also loses focus if you type too fast when defer/reject are disabled (for me anyway) 🫤

---

<div class="post-metadata">

**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\
**Post date:** [May 8, 2025, 2:04pm UTC](https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993/3 "2025-05-08T14:04:16Z")

</div>

I'm not seeing that in a simple view with just a TextArea. I have seen it clip the last two or three characters when I type too fast in my development views, but those have bindings and change scripts attached so I can't tell if it's a bug in the TextArea itself.

---

<div class="post-metadata">

**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\
**Post date:** [September 3, 2025, 5:26pm UTC](https://forum.inductiveautomation.com/t/bug-textarea-clips-first-enter-newline-after-refocus/105993/4 "2025-09-03T17:26:10Z")

</div>

Here’s a simpler test case: With `rejectUpdatesWhileFocused` set to False, type a word, then select it and hit ENTER. If the word doesn’t immediately reappear, it will after you click outside the text area:

![chrome_as7cTpZNXw](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/2/525d41255ec22cf022da242e2779bf3b6860e822.gif)