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

Status: NEW

(Core :: Web Painting, defect)

Description

[Julien]

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

[Thomas Ahlblom]

Reproduced using Linux:

18% CPU
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.19) 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

Comment 2

[Thomas Ahlblom]

Looking for a regression...

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

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73ab2c3c5ad9&tochange=cd3c926a7413

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.

Comment 3

[Thomas Ahlblom]

Local track down using Linux:

Due to skipped revisions, the first bad revision could be any of:
changeset:   52479:11cf38adabf3
user:        L. David Baron <[e-mail]>
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 <[e-mail]>
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

[Thomas Ahlblom]

Attachment: Testcase from comment 0.

Comment 5

[Thomas Ahlblom]

Attachment: 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.

Comment 6

[Timothy Nikkel (:tnikkel)]

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.