Hide Forgot
Description of problem: After installing Fedora 11, the new version of Firefox has serious performance problems compared to Firefox 3.0 in Fedora 10. I am a web developer and some pages of an enterprise application I'm working on are showing serious performance degradation while being used. The problem is not during the page loading or page rendering but while the user is interacting with the form elements in the web page. Every once in a while, when the user tries to fill in a form input (eg. text box, radio button, select or check box) the browser freezes for about 3 or 5 seconds consuming 100% of the CPU, it doesn't happens all the time but often enough to be very annoying. The problem is specially bad with big and complex pages, for example, I have a web page with well over 700 form elements (including hidden input elements) and some of the elements have JavaScript code used to validate input data or to perform calculations while the user is typing. But the great news is that I managed to make a simple test case with 100 check boxes and with no JavaScript at all. I'll attach the test case later. Version-Release number of selected component (if applicable): As I am a web developer I installed addons like LiveHTTP Headers and Firebug, but I uninstalled everything for the test including the Flash plugin and the Java plugin, so this is basically the simplest installation of Firefox ever. [root@nalwalovaton ~]# rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin* plymouth-plugin-label-0.7.0-0.2009.05.15.1.fc11.i586 xulrunner-1.9.1.2-1.fc11.i586 setroubleshoot-plugins-2.0.18-5.fc11.noarch gstreamer-plugins-flumpegdemux-0.10.15-6.fc11.i586 alsa-plugins-pulseaudio-1.0.20-2.fc11.i586 mozilla-filesystem-1.9-4.fc11.i586 plymouth-plugin-two-step-0.7.0-0.2009.05.15.1.fc11.i586 anaconda-yum-plugins-1.0-4.fc11.noarch gedit-plugins-2.26.1-1.fc11.i586 nspluginwrapper-1.3.0-6.fc11.i586 gdm-plugin-fingerprint-2.26.1-13.fc11.i586 gstreamer-plugins-bad-0.10.13-3.fc11.i586 firefox-3.5.2-2.fc11.i586 PackageKit-gstreamer-plugin-0.4.8-2.fc11.i586 gstreamer-plugins-base-0.10.23-3.fc11.i586 totem-mozplugin-2.26.3-1.fc11.i586 gstreamer-plugins-good-0.10.15-4.fc11.i586 yum-plugin-fastestmirror-1.1.22-1.fc11.noarch PackageKit-yum-plugin-0.4.8-2.fc11.i586 gstreamer-plugins-ugly-0.10.12-1.fc11.i586 How reproducible: Use a big web form with several elements and watch the CPU usage in top, I'll explain it in detail when I attach the test case later. Actual results: Firefox sometimes block unexpectedly for a few seconds consuming 100% of the CPU with no apparent reason. Expected results: Firefox should have better performance, specially since that is one of the big new features in the latest release. Additional info: This problem also triggers in some other ways, sometimes when you scroll the page with the mouse wheel, it freezes for a little while and then starts scrolling abruptly. The other way is when you change the focus of the window using Alt + Tab and when you go back to Firefox it freezes for a while until it redraws the window properly. As I said before this doesn't happen all the time but often enough to be incredibly annoying. Also, remember using a not so powerful CPU so you can see the effect, right now I'm using Intel(R) Pentium(R) 4 CPU 2.80GHz Dual Core (or HT since I see two CPUs in gnome-system-monitor) which is by no means a weak CPU. I still can see this problem at home with an Intel Core 2 Quad 2.4 GHz.
Created attachment 358136 [details] Simple test case for firefox performance The test is simply a web page with a form containing 100 check boxes. Steps to reproduce: 1. Download the HTML page in your local filesystem 2. Open the file with Firefox 3. Open top in a terminal window 4. Change it to refresh every second (press "s", then "1" and then Enter) 5. Order the list by memory usage so Firefox is always at the top (press "m") 6. Click through several check boxes back and forth quickly, after a few seconds it freezes for a second while the CPU starts climbing to 100%, after the freeze the check box is checked or unchecked accordingly. 7. You can also reproduce the problem by clicking the same check box over and over until it freezes. As I said in the first post you can also try to trigger this problem by scrolling with mouse wheel or by changing the focus back and forth with Alt + Tab. For the test my computer was completely idle with top showing 99% or 99.5% of idle time. If it's still difficult for you to reproduce this problem trying increasing the number of check boxes to 200 or 300. Possible suspects: 1) I always thought it was a Pango problem since font rendering is always complex and there is already a history of Firefox being slow because of Pango. But I don't think this is the case. 2) May be the spell checker is having problems with such a huge number of input elements. I'll try to redo the test with spell checking disabled.
The situation seem to be improved in Fedora 12 a little bit but the test still applies. It is very common to be browsing around and all of a sudden the browser blocks for a few seconds doing something with the CPU. The problem seems to be very common: http://www.gnome.org/~michael/blog/2009-12-03.html
Are you able to reproduce this with the upstream binary from www.mozilla.com?
Yep, I downloaded the latest binary from mozilla.com and I can see the same problem there.
I will file your bug upstream, but could we get also spec for your computer, please? I cannot reproduce this on my notebook (arguably beefy, dual core 2.5GHz,4GB RAM).
(In reply to comment #5) > I will file your bug upstream, but could we get also spec for your computer, > please? I cannot reproduce this on my notebook (arguably beefy, dual core > 2.5GHz,4GB RAM). Matej, the problem is a lot more obvious on a low spec computer. My laptop is a Core Duo 1.8 GHz so the problem is not that notorious. At work I have an old workstation, Intel(R) Pentium(R) 4 CPU 2.80GHz so the slowness is more evident. The problem is that this is a Fedora 11 system but the Firefox version is the same as Fedora 12 so I guess it's ok. Do you want me to do more testing here? maybe a sysprof log with debugging packages? Please remember to cross reference the upstream bug report with this one.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. First of all, could we get output of the command rpm -qa \*xulrun\* \*firefox\* \*mozilla\* \*flash\* \*plugin\* Please also install firefox-debuginfo (debuginfo-install is from yum-utils package). debuginfo-install firefox Please, install also valgrind (from valgrind package) and run valgrind --trace-children=yes \ --log-file=/tmp/firefox-valgrind-log.txt \ /usr/bin/firefox (that's one line command, being broken into three lines notwithstanding) Please, attach the file /tmp/firefox-valgrind-log.txt to this bug as an attachment as well. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
BTW, just to note ... this is just for a brief test ... if you think your Firefox was slow, let it run in valgrind, you will experience something !
Hello, sorry for the delay. I'm really interesting in investigating and solving this issue. First post... # rpm -qa \*xulrun\* \*firefox\* \*mozilla\* \*flash\* \*plugin\* xulrunner-1.9.1.6-1.fc12.i686 nspluginwrapper-1.3.0-10.fc12.i686 gedit-plugins-2.28.0-1.fc12.i686 abrt-plugin-bugzilla-1.0.0-1.fc12.i686 plymouth-plugin-label-0.8.0-0.2009.29.09.19.fc12.i686 gstreamer-plugins-ugly-0.10.13-1.fc12.i686 xulrunner-debuginfo-1.9.1.6-1.fc12.i686 abrt-plugin-sqlite3-1.0.0-1.fc12.i686 plymouth-plugin-two-step-0.8.0-0.2009.29.09.19.fc12.i686 anaconda-yum-plugins-1.0-5.fc12.noarch gnumeric-plugins-extras-1.8.4-6.fc12.i686 gstreamer-plugins-bad-0.10.17-2.fc12.i686 gstreamer-plugins-base-0.10.25.1-2.fc12.i686 nspluginwrapper-debuginfo-1.3.0-10.fc12.i686 abrt-plugin-kerneloopsreporter-1.0.0-1.fc12.i686 firefox-3.5.6-1.fc12.i686 gdm-plugin-fingerprint-2.28.1-25.fc12.i686 mozilla-filesystem-1.9-5.fc12.i686 gstreamer-plugins-good-0.10.17-3.fc12.i686 firefox-debuginfo-3.5.6-1.fc12.i686 PackageKit-yum-plugin-0.5.4-0.4.20091029git.fc12.i686 gstreamer-plugins-flumpegdemux-0.10.15-8.fc12.i686 abrt-plugin-logger-1.0.0-1.fc12.i686 flash-plugin-10.0.42.34-release.i386 PackageKit-gstreamer-plugin-0.5.4-0.4.20091029git.fc12.i686 yum-plugin-fastestmirror-1.1.24-2.fc12.noarch totem-mozplugin-2.28.4-1.fc12.i686 setroubleshoot-plugins-2.1.35-1.fc12.noarch java-1.6.0-openjdk-plugin-1.6.0.0-33.b16.fc12.i686 alsa-plugins-pulseaudio-1.0.21-2.fc12.i686 Next post... the valgrind output.
Created attachment 380283 [details] valgrind's output This is the output of a firefox session under valgrind. It was for about 10 minutes. I have to say that the problem is a lot easier to trigger under valgrind even with a powerful CPU. You can use top (refreshing every second) side by side with firefox and run the test attached to this bug report in comment #1. If you let firefox idle it won't consume any CPU, but then if you try to click one checkbox over and over (I prefer to do it with the space bar) it will be responsive for a few seconds until it blocks with a high CPU consumption. It then blocks for more than 20 seconds (in my case) until it gets responsive again. You don't even have to click the checkbox over and over, you just have to click once and wait a few seconds for it to go high on the CPU, wait a lot of time for it to settle down and then click once again to see the same effect again. I'm going to test if this has anything to do with the huge number of check boxes on the test page and report back.
Ok, I can confirm that this slowness is related to the number of form elements. I made the same test with 1, 2 and 3 checkboxes and there is no high CPU consumption. Just about 60% for about 1 or 2 seconds. I then made the original test replacing all the check boxes for text boxes except for the first one. Again, the slowness is reproducible, just clicking once on the checkbox fires up the CPU consumption to constant 100% for more than 20 seconds. The problem is that my web application has some huge forms for a medical chart for pregnant women and there are a lot of form elements there. Next test: check if this is reproducible on Windows, it's a shame there is no valgrind there.
We filed this bug in the upstream database (https://bugzilla.mozilla.org/show_bug.cgi?id=536910) and believe that it is more appropriate to let it be resolved upstream. We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report.
Reporter, could you please join the upstream bug, please, or should I answer instead of you? "... does changing the "browser.sessionstore.privacy_level" preference to the integer 2 make the problem go away? This is sounding a lot like bug https://bugzilla.mozilla.org/show_bug.cgi?id=477564 (certainly that's what the testcase looks like). But that claims to be fixed in 1.9.1.3, by capping to 100 elements. Since you only have 100 elements, it might be that in your case even doing 100 elements takes too long...." Thank you very much