Looks like I can't edit the original post, so here's the reproduction code in a codeblock:

document.body.innerHTML = `<textarea id="textEl" spellcheck="false" style="width:100%; height:100%; font-family:monospace; white-space:pre-wrap;"></textarea>`;
textEl.value = new Array(2_000_000).fill(0).map(_ => "a").join(" ");

Could you please confirm if the issue is similar to crbug.com/341406781

The issue is not related - I specifically added spellcheck="false" to ensure this.

You have correctly replicated the issue. Thanks!

Yep, the wrapping problem is a bug, so 114 still has an issue here.

Been a few months now, so just checking in - any chance this can be looked into? Interaction on text areas with book-length text is very laggy (and "crashy") on Chrome, but fine on Firefox.

As mentioned above, repro is very simple:

document.body.innerHTML = `<textarea id="textareaEl" spellcheck="false" style="width:300px; height:300px;">${"a ".repeat(2_000_000)}</textarea>`;
textareaEl.scrollTop = textareaEl.scrollHeight;

Then just try typing into the textarea.

On smartphone the number of characters can be significantly smaller to replicate the issue. On low-end phones, Chrome's textarea is really really bad for long text.

Reproduces on my gMac laptop - last line wrap is clearly wrong; does not reproduce on my gLinux desktop - last line wrap is correct.

new Array(2_000_000).fill(0).map(_ => "a").join(" ")

Reporter,

Are you concerned about performance on a single giant paragraph with no line breaks? If you're concerned about performance on multiple paragraphs with line breaks, that's relatively easy to improve.

If I had to guess, at least 95% of the time that the problem occurs "in the wild" on my experience (i.e. real user problems, not contrived/edge/weird cases), there are line breaks. I.e. lots of paragraphs.

That remaining 5% might seem quite high, but it's because there is one "weird" case which is not super uncommon: data URLs. I don't know the exact percentage to put on it, but it's a non-trivial amount. Much less common than the lots-of-paragraphs case though.

(Aside: This data URL problem also exists with <input> elements where the application generally expects a URL, but can also handle a data URL. Even when using a monospace font, turning off spellcheck, etc. there was still significant lag last time I checked, but I don't think I've ever had reports of page crashing or at least being able to replicate page crashing. Just significant lag, especially on low end devices. And no lag on Firefox. But there could be a separate underlying cause to this <textarea> case.)

Thank you for the information. Now I understand both of a giant paragraph and huge number of paragraphs are problematic.

I have filed Issue 414858401 for the issue with huge number of paragraphs. Let's focus on the issue of a giant paragraph here.