Poor performance of contenteditable together with floated parent and box-shadow




Layout: View Rendering
6 years ago
6 years ago


(Reporter: Julien, Unassigned)


({perf, testcase})

perf, testcase

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Build ID: 20110707182747

Steps to reproduce:

We were having performance complains from some of our clients using content editable in one of our product. After some debugging, we managed to bring it down to the following :

- Put a content editable inside an element with float property and some amount of text
- Hold down any key inside the content editable and look at your cpu usage

Online test case : http://www.nethik.fr/firefox-content-editable-debug.html

We've reproduced this bug on Firefox 5.0.1 under Mac OS X 10.6.8 and Firefox 5.0 under Windows XP. On windows Vista, we didn't see any increase but the performance alltogether is very bad = 3 to 4 times more cpu usage than other browsers.

Actual results:

- When the content editable is inside the floated element the cpu usage is 2 to 3 times more than an element not floated
- If you scroll down the page the cpu usage usualy gets even worse
- The more content there seems to be in the page, the worse the performances seems to get

In general, Firefox (compared to all other browsers) seems to have poor performances when dealing with content editable elements.

Expected results:

Probably Firefox shouldn't use that much CPU?

Comment 1

6 years ago
Reproduced using Linux:

18% CPU
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20110707 Firefox/3.6.19

28% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1

27% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0

27% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110727 Firefox/7.0a2

27% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110727 Firefox/8.0a1

7% CPU
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30

12% CPU
Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.50
OS: Other → All
Version: 5 Branch → Trunk

Comment 2

6 years ago
Looking for a regression...

Last good nightly: 2010-09-11
First bad nightly: 2010-09-12


6% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre

25% CPU
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre

Perhaps J├Ągermonkey has something to do with this.
Keywords: regression

Comment 3

6 years ago
Local track down using Linux:

Due to skipped revisions, the first bad revision could be any of:
changeset:   52479:11cf38adabf3
user:        L. David Baron <dbaron@dbaron.org>
date:        Sat Sep 11 09:27:12 2010 -0700
summary:     Rename -moz-box-shadow to box-shadow: mechanical changes.  (Bug 590039)  r=bzbarsky  a2.0=blocking2.0:beta6

changeset:   52480:83a79e1e035b
user:        L. David Baron <dbaron@dbaron.org>
date:        Sat Sep 11 09:27:13 2010 -0700
summary:     Rename -moz-box-shadow to box-shadow: manual changes.  (Bug 590039)  r=bzbarsky  a2.0=blocking2.0:beta6

Comment 4

6 years ago
Created attachment 549219 [details]
Testcase from comment 0.

Comment 5

6 years ago
Created attachment 549221 [details]
Modified testcase without box-shadow

8% CPU without box-shadow
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110728 Firefox/8.0a1

Apparently it looks like Firefox requires far more CPU to handle box-shadow in combination with floating contenteditable compared with other browsers. Also Firefox compared with itself shows box-shadow requires much CPU power.


6 years ago
Keywords: regression


6 years ago
Component: General → Layout: View Rendering
Ever confirmed: true
Keywords: perf, testcase
Product: Firefox → Core
QA Contact: general → layout.view-rendering
Summary: Content editable poor performance in specific cases (ie: floated parent) → Poor performance of contenteditable together with floated parent and box-shadow
box shadow isn't a quick operation, and we have a bug where if things inside a float change we invalidate too much of the page. That would explain this bug.
You need to log in before you can comment on or make changes to this bug.