adding text in <textarea> uses way too much CPU, inserting doesn't




Layout: Web Painting
2 months ago
14 days ago


(Reporter: Ale, Unassigned)


57 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



2 months ago
Created attachment 8934750 [details]
example HTML code triggering the issue (for best results maximize the browser window)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20171107091003

Steps to reproduce:

Noticing a remarkable slowness in a textbox while developing a WebExtension for Firefox, I tried to isolate the problem to figure out what was happening. Basically, when editing text in a big <textarea> element, adding text at the end (which includes typing text inside the empty textarea) is very CPU-intensive and slow (especially if the textarea is particularly large, even if empty). Surprisingly, _inserting_ text before the last character does not trigger the problem. I tried disabling the spellchecker, but there is no change.

Actual results:

Adding text at the end of the textarea is WAY too slow (~4 characters per second while keeping a key pressed on a modest i7-4500U CPU) and can be easily seen as heavy CPU use in the task manager. Inserting before the last byte is perfectly fine. I  tested this on Windows 7 x64, not sure what other platforms are affected. Firefox 57.0.1 and Firefox Developer 58.0b9 are both affected (the latter feels even worse).

Expected results:

Adding text at the end of the textareas should not be different and should definitely be faster. For a large textarea on a low-end laptop, users can definitely feel the unresponsiveness of the interface while typing!

Comment 1

2 months ago
Automatically-inserted user agent in the bug report is not the affected version (I can't observe the problem in Firefox 52 ESR). Actual affected UA is Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0. Build ID is 20171128222554 (Firefox 57.0.1 Win64).

Comment 2

2 months ago
The bug is more difficult to perceive on a high-end machine (just tried on a i7-4790K at 4 GHz), but the increased CPU usage is clearly visible (especially when comparing to the same HTML code displayed on Firefox 52 ESR).


2 months ago
Component: Untriaged → Editor
Product: Firefox → Core
Since I don't have Windows PC now, as long as I test this on macOS, slow point seems to be nsNativeThemeCocoa::DrawWidgetBackground.  After I test this on Winodws, I will set priority (and change component if needed)
nsDisplayThemedBackground::Paint spends more time for this operation on Windows.  I guess that this issue is Web Paint or Widget.
Component: Editor → Layout: Web Painting
Looks like an invalidation issue.

Turning on paint flashing in devtools shows that we frequently repaint all the text in the <textarea> every time we add a new character.
Ever confirmed: true
Priority: -- → P2

Comment 7

14 days ago
It is indeed the case, however inserting or adding characters at the end of the text doesn't seem to make any difference in the repainted area (the full text in all cases). However, inserting characters at the end of the text is much slower than inserting them before the end. I can't almost see this on my fast PC, but on the laptop it is awfully slow.

Just did some further tests:
  * the bug is still present in the latest dev version (58.0b14) on Win64
  * can't reproduce it on Linux (or at least it is not visible enough to notice it) (tested on 57.0.4, Ubuntu 14 x64, same laptop)
  * disabling hardware acceleration makes the situation much better (graphics card tested: integrated Intel HD 4400, driver v. from Jan 2017, Win7 x64): I still feel that adding text at end is slower than inserting in the middle, but it got at least 10x faster than before — I have the impression that the particular configuration I first observed the bug on (slow laptop + hardware acceleration with that specific card & driver) makes it particularly annoying
You need to log in before you can comment on or make changes to this bug.