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?
Reproduced using Linux: 18% CPU Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) 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
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.
Local track down using Linux: Due to skipped revisions, the first bad revision could be any of: changeset: 52479:11cf38adabf3 user: L. David Baron <firstname.lastname@example.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 <email@example.com> 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
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.
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.