User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070505 Minefield/3.0a5pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070505 Minefield/3.0a5pre Beginning with the 5-01-07 trunk build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070501 Minefield/3.0a5pre), loading pages that use AJAX causes CPU usage to be maxed out and the system to grind to a halt. The problem persists with today's build; it did NOT exist prior to the 5-01 build. Reproducible: Always Steps to Reproduce: 1. With google calendar: a. Load google calendar's month view b. Click on the ">" button to view the next month c. Click on menus, try to get into the address bar, give focus to another window, etc. 2. With netvibes: a. Load netvibes b. Click on menus, try to get into the address bar, give focus to another window, etc. Actual Results: There is a *significant* delay between the time you give the command via the mouse or keyboard to the time it is actually executed. Expected Results: There would not be a significant delay between the time you give the command and the time it is executed. This is on Ubuntu Feisty Fawn, fully updated, 2.2GHz dual-core AMD processor with 2GB RAM over a broadband (cable) connection. Marking the severity as "major" because the delay is such that I cannot use the current builds to effectively use my calendar or access content on netvibes.

Perhaps this bug should be renamed to the more generic "javascript" maxes things out, but I'll leave that to someone else. :-) Another data point: 1. Navigate to slashdot.org 2. Use Tab to move from link to link on the top navbar. When you get to the final link in the navbar ("x"), press Tab once and wait. Notice how long it takes for the focus rectangle to move off of the "x" link. Shift Tab to move focus back to the "x" link. Again, notice the delay. Also, with slashdot loaded, I'm seeing significant overall system sluggishness. I then reverted back to the April 30th build and the issues (delay when tabbing, system sluggishness) went away.

I think this may be a regression from bug 368247. Should keep an eye on bug 379437 and retest when it gets fixed.

Thanks Adam. I'll do that. Hopefully that will happen soon as things are pretty bad. Another example is the advanced search of GNOME's bugzilla: http://bugzilla.gnome.org/query.cgi (choose complicated bug search) The delay that occurs when you choose various items in the Classification list is painful -- and, again, it didn't used to be an issue....

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/2007060115 Firefox/2.0.0.4 (Ubuntu-feisty) I can confirm the issue in GNOME's bugzilla on a Centrino 1,7Ghz, 1Gb RAM machine. Besides (don't know whether this is relevant here), an idle firefox with only a netvibes.com page open eats up to 30% CPU. If you go to any other web (thus leaving netvibes), CPU goes closes down to 0% when idle. Really annoying behavior here I hope gets fixed. I really don't have any idea on how to debug it, but maybe if anyone gave me some clues, I could be of help.

joanmarie, do you see this problem with current beta of 3.1? http://www.mozilla.com/en-US/firefox/all-beta.html

I didn't realize this bug is still opened (and missed your comment Wayne, sorry!). I've not seen this bug in quite some time.

=> WFM