User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 While using Firefox 3.0.x continuously, it periodically becomes irresponsive: videos jerk and/or pause; links in web pages don't work; cannot switch to other open tabs; menus don't work; toolbars don't work; mouse pointer doesn't change shape while hovering links, forms, etc... This lasts for a few seconds, then everything comes back to normal. The issue repeats again every few minutes. This seems more prone to happen when playing embedded video and/or with multiple tabs open, specially with many images/flash. It also seems to occur more frecuently the more time Firefox keeps running. Reproducible: Always Steps to Reproduce: 1. Open a few sites in different tabs --at least one of them with embedded video. 2. Notice that Fx periodically becomes irresponsive after being running for a while (jerky/paused video, scroll not responding, cannot switch to other tabs, etc.) 3. Actual Results: Fx periodically becomes irresponsive (jerky/paused video, scroll not responding, cannot switch to other tabs, etc.) while the rest of the system remains responsive. Expected Results: Fx should always run smoothly. I started noticing this kind of problems since version 3.0.2/3. I checked browsing the same sites, same open tabs with other browsers, but they didn't show this issue.

Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Seeing the same issues in the above build - pretty much exactly as described. It does increase with the number of open tabs and how long Firefox has been running. The pause interval is usually in the 0.5s-1.5s range, while the interval between pauses is around 4s-30s (that's how I perceive it anyway; these are by no means accurate measurements). Numerous threads exist online with plenty of users reporting this, however this is the only Bugzilla issue I managed to pinpoint. Odd. A collection of links with people reporting this (which could be of relevance): - http://groups.google.com/group/mozilla.feedback.firefox/browse_thread/thread/eca33e3c178cf4e6?fwc=1 - http://www.digitalspy.co.uk/forums/showthread.php?t=884222 - http://support.mozilla.com/tiki-view_forum_thread.php?locale=eu&comments_parentId=176813&forumId=1 - http://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=396847 There's also Bug 477852, which appears to be the Mac OS X equivalent. Importantly, while most reports complain specifically about videos, I think most people simply don't notice when it happens at other times. For me it definitely happens anywhere, not just on Flash videos. My platform is x64 Vista.

I have noticed this issue not only with embedded video, but with animated GIFs in message board postings.

Reporter here: This happens anywhere, but seems more noticeable with: videos/flash, many tabs, webs with many images and the longer Fx keeps running.

It should be noted that when there's a stutter during a video, the image pauses but the sound continues to play. When the stutter is over and the video starts playing again, it is in sync with the audio.

Some people are reporting this when using lots of tabs, I just want to add that I don't use tabs and experience exactly the same problems: stuttering video but no problems with sound, stuttering when typing in messageboxes, scrolling over webpages, switching between FF windows and clicking links. I never had this issue before, until one of the very latest FF releases. I think I noticed it first right after upgrading to 3.5.0 (from the latest stable version before that). WinVista SP2, Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Extensions: Xmarks, FlashGot, DownloadHelper, DOM Inspector, latest Flash.

In my opinion, Bug 484964 should be marked as a duplicate of this bug. ("Flash players stutter during video or game playback every ten seconds or so - lasts for 1 to 2 seconds, then continues.") I had these problems already in 3.0. The fact that some people got aware of the problems first in 3.5 (or some other specific version) could possibly indicate that the problem depends on some suddenly appearing "illness" that every installation does not have from the start, and that could be harder to find a description of how to find and debug. Some people indicate that the problem could depend on the number of bookmarks, or corrupted bookmarks. But when I made a fresh FF installation and restored (via Mozbackup) ONLY my "General settings" - not bookmarks, not history, not cookies etc - the same old problem appeared anyway. (The "General settings" include tabs and some more stuff I don't know in detail, but here's a pic of the Mozbackup choices for reference: http://gopaultech.com/wp-content/images/mozbackup.jpg ) I recently made the workaround mentioned in Bug 484964 (increased the preference browser.sessionstore.interval from 10,000 to 120,000 milliseconds to prevent frequent disk writes etc) and initially thought the whole problem was over, but it was not. There is still something that makes FF freeze, and the problem accumulates over time just like before. It feels like the freezes now are perhaps a bit shorter less occurring, but still bad. (See my picture just posted - there are some new freezing periodicity that should be looked into.) An interesting step forward, though, is that FF consumes notably less CPU now after the workaround. It now lies at 5-10% rather than 10-20%. Although halving it doesn't free up much more resources, it makes my laptop run cooler and the otherwise noisy fan now goes down to its lowest speed for parts of the time, which it almost never did before. This is a great improvement! But as I said, there is still some freezing behaviour with the browser.sessionstore.interval preference increased. Is this related to sessionstore or is it something else? I have tried to find a quick and easily reproducible way of reaching obvious freezing problems, but the only good clue I find is that it increases more when the memory used by the Firefox process is reaching some limit where (I guess) it's starting to written to disk by Windows. When looking at the Windows Task Manager's "Performance" tab, the Memory Usage History curve goes up as I open more tabs etc, but somewhere close to the top it sometimes goes down a little bit again, then up, then down and so on. I guess Windows manages the memory into the Pagefile when FF grows too much, and it feels like there is not much freezing problems before this limit is reached. After it is reached, the problems tend to get worse and worse over time. Some people will almost never reach this limit, just because they use the browser differently. When looking for this problem, it might be handy to do it on a computer with less memory installed, or to run hungry programs alongside FF. Although freezing the whole graphical rendering, this bug shows itself primarily by jerky Flash movies, and people think Flash is the problem. Otherwise LOTS of people would report this bug. I'm personally not a YouTube addict or Flash gamer, so Flash is not the biggest issue for me. Instead, the most annoying things with this bug are probably 1) the lagging cursor/text response in input fields 2) that the modifier keys and mouseclicks get misaligned so that my shift+clicks and ctrl+clicks - or normal clicks too near a ctrl+tab, alt+tab, ctrl+c, ctrl+v etc - is interpreted like something else than expected. (This is described in Bug 145313 - "Ctrl/Shift/etc state should be registered at click time, not later when loading/processing".)

(In reply to comment #7) I also experienced improvement by changing browser.sessionstore.interval and some other tweaks. But, just like mr@analogue.org explains, the problem is not completely gone --just alleviated-- and it increases with time.

I get this a lot on Hulu.com videos, and it seems to have started happening with Firefox version 3.5. I'm on Windows Vista with latest Flash version (recently re-installed too) and only three extensions (FireFTP, Adblock Plus, Email This).

(In reply to comment #9) > I get this a lot on Hulu.com videos And you probably see it not only in videos, but everywhere - like when typing in text fields, scrolling webpages, watching animated GIFs etc? http://www.emoticones.com/emoticonos_bananas.php

The problem seems to diminish if not disappear when disabling Greasemonkey and applying the browser.sessionstore.interval tweak.

I haven't used Greasemonkey for a looong time. Also, in Safe Mode it is not used.

I get this only on Flash videos, but I do NOT get this when using Move Media Player. Video playback if fine there. But Flash in FF 3.5 is almost unwatchable. I do also notice the lagging cursor. I have tried to browser.sessionstore.interval tweak to no positive results. I do not use Greasemonkey.

Yeah problem seems to be only with flash here as well.. :(

This problem persists! It's *VERY* aggravating. Makes watching videos unbearable, on any service, youtube & vimeo. Any site that uses flash video that plays in Firefox has these stuttering problems. It's not only video either, it's everything from the interface to keyboard input, it feels like I'm typing on a terminal that gets periodic lag spikes or noise on the phone line. Even while typing this message I type and it pauses for a second or two then catches up. During that time the cursor does not blink, and no input is registered, then it all comes back like it was storred in a buffer and dumps it to the screen. This is ridiculous, fix this problem already! it's been like this for over a year!

I can confirm this issue on Windows 7 x64 RC: Flash 10,0,32,18 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) OS Name Microsoft Windows 7 Ultimate Version 6.1.7100 Build 7100 System Manufacturer Gigabyte Technology Co., Ltd. System Model GA-MA790X-UD4P System Type x64-based PC Processor AMD Phenom(tm) II X4 B50 Processor, 3516 Mhz, 4 Core(s), 4 Logical Processor(s) BIOS Version/Date Award Software International, Inc. F5, 6/3/2009 SMBIOS Version 2.4 Installed Physical Memory (RAM) 4.00 GB Total Physical Memory 4.00 GB Total Virtual Memory 8.00 GB Page File Space 4.00 GB Possibly related to this bug: https://bugs.adobe.com/jira/browse/FP-282 This bug is reproducible at: http://sandbox.headweb.com/sv/159766/filmer/pan-360-framebuffer-fail/ A lot of frame-dropping and tearing. It is so annoying to see flash stutter every minutes or so that I have to use Opera 10 when watching Flash videos. The above link both stutters and tears in FF 3.5.3, but it only tears in Opera 10. Hence, frame dropping is probably specific to FF + Flash 10 combo. This should be a high priority issue since most users watch YouTube and the like on a daily basis. I tried the video above on 4 different machines running FF 3.5.3 (AMD and Intel) and the symptoms are the same. I think it's time to set this bug to CONFIRMED and bring it to developers' attention that way.

please change status to confirmed.

Reporter here. I have no credentials to set the bug as confirmed. I'm a mere Fx user with a bugzilla account. Although, from the comments, the bug seems confirmed in XP, Vista and 7. What I can --and would like to do-- is to change the version affected from 3.0 to trunk, since 3.5.x still suffers the same problem. What do you guys think?

Yes, changing to trunk is a good idea, hopefully it will get better visibility among developers.

Yes, please change it to trunk. The problem persists with 3.5.x. I can also confirm jerky scrolling on webpages, something that I don't see in other browser. At first, I thought that the problem was with Gigabyte motherboards but this is not hardware specific.

Could anybody point me to where in the source code Flash, scrolling and animations are handled. I managed to compile from trunk but the codebase is (expectedly) huge and I want to make sure that I am looking at the right place. The developer's guide makes no mention (none that I know of) of where this is handled.

I compiled the debug build from mozilla-1.9.1 trunk (pre-3.5.4). I tried playing the "framebuffer fail" video and, apart from bunch of seemingly unrelated failed assertions", I only get this (in the debug console) when I press play: "For application/x-shockwave-flash found plugin C:\Windows\system32\Macromed\Flas h\NPSWF32.dll" The video stutters like crazy but no messages go to the debug console that would indicate where the problem is. I tried this in safe mode to rule out any interference from add-ons. I will continue to dig through the code when I have more time. Maybe I can find something, but this would definitely be more suitable for somebody who has experience with FF codebase.

@krylko GREAT! You seem to be able to recreate the problem. It won't be long until they have to confirm it then. Finally. :-)

I too have this issue, and have for a while. On XP SP3, using 3.5.3. Have any devs even noticed or acknowledged it yet? Doesn't look like it.

same here, problem gets worse as load more and more tabs, and affects animated gifs. I cant believe this isnt been confirmed, far too many reports to ignore, whats the problem, tough bug to fix? would love to see why not a single dev acknowledges this. Things like youtube are used heavily, it only damages FF rep to ignore the problem.

I see this problem as well... It gets worse as Firefox runs for a long time (and consumes more memory). Yesterday, Firefox was using over 800 MB of RAM with only five tabs open (a different problem altogether), and this issue was very easy to reproduce, even by just scrolling a page up and down (and seeing scroll stutter) or by holding down a button on the keyboard and watching characters appear in a text box (and seeing that stutter as well). I notice that the temporary freeze always corresponds with a spike in Firefox's CPU usage. I suspect that somehow, Firefox periodically becomes busy doing something else in the background, and does not update the screen until it is done. Since this gets worse as the amount of memory Firefox is using increases, I suspect that this may have something to do with memory management or cleanup, but this is just speculation on my part. Is there an easy way to figure out where the CPU cycles are being spent? If someone will point me towards some documentation, I'll take a stab at it. By the way, I'm using Firefox 3.5.3 on 64-bit Windows, but I've noticed this problem back to 3.0.x.

Hi, guys. Reporter here. I'm no programmer and I don't have the power to change this bug's status to 'confirmed'. Nevertheless, I can give you some tips on how to minimize the annoyances it causes. 1. Try this about:config tweak: http://lifehacker.com/5342636/how-to-fix-annoying-youtube-jumpiness-in-firefox "By opening about:config in your Firefox address bar, then typing browser.sessionstore.interval in the filter box, you'll see a value of 10000, which is in milliseconds. (Meaning your session is saved every 10 seconds.) I changed this to 300000, or every 5 minutes, as I don't have the urgent need for tab restoration. If you feel like being more on the safe side, try increasing it to something a bit lower, say 120000, or every 2 minutes." I set this to 60000, or every minute. 2. Another about:config tweak: browser. history_expire_days "Number of maximum days to remember visited pages in history. Default value is 9 for SeaMonkey and Firefox 2, 180 for Firefox 3. [...] No UI for Firefox 3." [1] Change this value to a lower value, e.g. 60 days, 30 days, 15 days... IMPORTANT: This value must be >= than the value you have in Tools > Options >Privacy "remember history for at least X days". 3. Another about:config tweak: browser. history_expire_sites "Maximum number of websites to keep in history. Default value is 40000." [1] You could try setting this to a lower value. It works well for me with just 1000 sites. 4. Try this add-on created to address database dirtiness in Firefox, which in turn leads to better performance and less lags: https://addons.mozilla.org/en-US/firefox/addon/13878 [1] http://kb.mozillazine.org/About:config_entries Hope this helps :)

Please try a Firefox 3.6 nightly build; Shawn Wilsher moved disk IO off the main thread which should resolve this in a much better way. I believe this is invalid/wfm with later builds, so clearing blocking nomination.

(In reply to comment #28) > Please try a Firefox 3.6 nightly build; Shawn Wilsher moved disk IO off the > main thread which should resolve this in a much better way. I believe this is > invalid/wfm with later builds, so clearing blocking nomination. The people seeing this who also have Firefox consuming a large amount of memory are likely seeing gc pauses (or cycle collector pauses, which happen at the same time).

Thank you for your response, Mike and Shawn. I'll try a nightly to see if it helps for me. Never done that before. For everyone who'd like to try a nightly as well, read this first: http://www.mozilla.org/developer/#builds And for anyone who is interested in reading more on this: http://shawnwilsher.com/archives/294

Will this fix be in next week's beta release?

(In reply to comment #31) > Will this fix be in next week's beta release? The fix[es] Mike talks about in comment 28 will be in the beta release.

(In reply to comment #28) This might be wfm/fixed by Bug 485976 and others in 3.6, but the bug was originally filed for 3.0.x half a year ago, and subsequently confirmed for 3.5.x. Is this bug fixed for Fx 3.0.15, 3.5.4 or 3.5.5? Is this bug fixed for Gecko 1.9.1.x ? If not, the bug description can be easily set to reflect the appropriate versions/builds. I won't hold a grudge whatever is done with this bug, seriously, but just let me say: This bug has remained officially unconfirmed for 6 months, and now it should be declared invalid because it doesn't affect --allegedly-- the latest nightly of Fx 3.6? >"which should resolve this in a much better way" <- Implicitly acknowledging there is, indeed, a bug? This bug had nearly 6 months to be set as dependent on / related to / duplicate of Bug 485976 or others that might solve it. Action taken: none. Remember Bug 485217, http://3.ly/sfz ? Thank Vishnu this time around the bug in question was not exploitable nor did it acquire public notoriety.

Downloading and running the latest nightly from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.7a1pre.en-US.win32.installer.exe. Same issues persist even in the nightly release for me. Testing page: http://www.blender.org/features-gallery/gallery/art-gallery/ (scrolling hickups) The video (http://sandbox.headweb.com/sv/159766/filmer/pan-360-framebuffer-fail/) shows some improvement, it only tears now. But, I am not sure how it would behave after an hour or so running Firefox because FF performance degrades with uptime. As Carlos suggested, this is too big of an issue to be handled this way. This is definitely a blocker for 3.7.

One more thing, the problem is likely I/O related because every time scrolling or video-play run into problems, there's extensive hard drive activity. If developers are too busy, they could at least give pointers on where to look (in the source code) to solve these issues, as the code-base is huge.

Quite honestly, this is bad enough to get me to switch to IE8. I play a lot of Flash games and watch videos on YouTube, and if the browser doesn't do what I need it to, it doesn't matter what features and coolness it has.. it doesn't work, I go someplace else until it gets fixed.

I agree with Madoc. I've switched to Chrome for the time being until this gets sorted out.

How many votes does it take to get noticed? Let's start a campaign. ;-)

(In reply to comment #35) > One more thing, the problem is likely I/O related because every time scrolling > or video-play run into problems, there's extensive hard drive activity. If > developers are too busy, they could at least give pointers on where to look (in > the source code) to solve these issues, as the code-base is huge. Just looking at code is surely a waste of time. What you should do is use a profiling tool to actually see where the time is spent. As for the rest of the folks commenting: Comments complaining about the lack of developer attention to an issue is a great way to make developers stay away. Developers have a finite amount of time, and they don't want to spend it reading a bunch of e-mails from bug comments that don't actually help get the bug fixed. Please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html for the proper use of bugzilla.

I wasn't completely sure what nightly to pick to get a good idea of the improvement. I ended up with using a 3.5.4 nightly: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.5.4-candidates/build1/win32/en-US/Firefox%20Setup%203.5.4.exe / Gecko/20091007 Firefox/3.5.4 I've been running this version for a couple of days and the problem is still there with the same symptoms and in the same severity as before. I will try a newer nightly this week, although I doubt I'll find any improvements on this particular problem.

You will not find improvements in 3.5.x nightlies. You'd want to check 3.6 nightlies, or 3.7 nightlies: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ You should create a new profile when testing these builds so you don't break your normal profile: http://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile

(In reply to comment #33) > This bug has remained officially unconfirmed for 6 months, and now it should > be declared invalid because it doesn't affect --allegedly-- the latest > nightly of Fx 3.6? First, because it was alleged, you'll note I didn't resolve the bug as INVALID; I merely recommended a course of action had the bug been fixed. If the bug is resolved in those nightlies, then INVALID is the right resolution, and the appropriate bugs which fixed the problem should be nominated to block the other branches if that's your desire. The resolution doesn't mean that we're saying the bug doesn't exist in some versions of Firefox, it's just the way we use bugzilla. Finally, a screencast or solid STR/testcase would cause this bug to move to NEW state immediately. I've seen this enough and there are enough comments that I think it should be CONFIRMED on 1.9.0.x (changing flags to reflect that with this comment) (In reply to comment #34) > Downloading and running the latest nightly from > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.7a1pre.en-US.win32.installer.exe. > > Same issues persist even in the nightly release for me. > > Testing page: http://www.blender.org/features-gallery/gallery/art-gallery/ > (scrolling hickups) > > The video > (http://sandbox.headweb.com/sv/159766/filmer/pan-360-framebuffer-fail/) shows > some improvement, it only tears now. But, I am not sure how it would behave > after an hour or so running Firefox because FF performance degrades with > uptime. ^ that's certainly not the case with my install of Firefox, which has an uptime in the days-to-weeks and doesn't degrade, performance wise. I think if you're seeing degrading performance you should be testing with a clean profile, as there may be bad interactions with other software referenced in your existing one. > As Carlos suggested, this is too big of an issue to be handled this way. This > is definitely a blocker for 3.7. To be handled which way? So far I haven't seen any evidence as to why this would block Firefox 3.6 (which isn't saying that it isn't a problem or a bug - just that I don't have a good sense for how commonplace it is) but it's something we should continue to address for 3.7 and the future. My feeling is that the problem is systemic, more to do with how our UI and rendering process are shared and can block each other.

I've started running the 3.6b1 nightly as of about 15 minutes ago, and it already looks better. I'll give more feedback in the next few days.

Extremely happy to report that after 24 hours, the nightly is going great! Over half the memory usage, and no stuttering on YouTube videos. The previously referenced video test still shows a little tearing... but the freezing/stuttering has disappeared.

Going going excellently -- this build certainly fixes both stuttering AND memory leak issues it would seem. BIG problem with it though; tab restoration seems to be really, really hit and miss, and I can't live with that any longer, so going back to a release version for now.

(In reply to comment #41) > You will not find improvements in 3.5.x nightlies. You'd want to check 3.6 > nightlies, or 3.7 nightlies: Thank you for suggestion. I tried the Gecko/20091013 Minefield/3.7a1pre (with a clean profile) after reading your comment. I notice some improvement, not very spectacular however: - it seems to take a little longer for the pauses to appear. Minefield is now running for 6 or 7 hours and memory consumption is at 620 MB for the last 15 minutes according to the task manager. I'm using 6 windows currently. - the pauses seem a little bit shorter. The pauses are still very noticable though. I can still see CPU-usage spikes up to around 50%, about every 20 seconds, exactly when a pause occurs.

Can anyone explain to me why Firefox is saving the session periodically, anyway? Why can't it just save it only if it has changed?

(In reply to comment #47) > Can anyone explain to me why Firefox is saving the session periodically, > anyway? Why can't it just save it only if it has changed? It is saved only whenever something changes. However, scrolling a page is a change, so... (Note: folks may be thinking that it happens ever ten seconds because of what I have said in my blog that got picked up by other places. After further investigation, we determined that that was incorrect, and this comment contains a more accurate representation of what happens. Sorry for the confusion.)

> It is saved only whenever something changes. However, scrolling a page is a > change, so... If this is true, then why are YouTube videos stuttering when the user is only looking at them and not scrolling or doing anything else? It would seem, then, that session saving is not actually the cause of the stuttering?

(In reply to comment #49) > > It is saved only whenever something changes. However, scrolling a page is a > > change, so... > > If this is true, then why are YouTube videos stuttering when the user is only > looking at them and not scrolling or doing anything else? It would seem, then, > that session saving is not actually the cause of the stuttering? Adjusting session saving rates did nothing for me. The stuttering continued as often as ever.

(In reply to comment #50) > Adjusting session saving rates did nothing for me. The stuttering continued as > often as ever. Your statement assumes that session restore is the reason for that stuttering, right? We wanted to determine if session restore was the cause of the issue, and that's why we had folks try the newer builds with the fixes to session restore in them. Since the issue is still persisting, I think it's safe to say that session restore is not the [primary] cause of the hangs folks are seeing.

(previous comment was meant to be a reply to comment 49)

I gave FF3 a try in Arch Linux (rolling release 2009.8). Same scroll and video stutter as in Windows. Considering that it happens in OS X too, it's fairly safe to conclude that this issue is not platform specific (at least not entirely). As I said earlier, 3.7a1 nightly was a bit better but still not acceptable because stuttering comes back again (confirmed by another poster). Perhaps somebody could point to a resource on profiling Firefox so that we (those who experience these issues) can identify (or help identify) where the bottleneck is.

Forgot to mention that I was using Firefox 3.5.3 (x64 build) in Arch to verify whether the same issue exists.

The profiling tool depends on your system, but there are a number of different ways listed here: https://developer.mozilla.org/Special:Search?search=profile

I'm not sure I can make myself of much use on profiling since I'm not familiar with it. If someone has a n00bs guide to profiling Minefield on Win7/64b I'd be willing to give it a try. Did a quick search using Google but didn't find anything that suited my needs.

On windows, it's best to probably use https://developer.mozilla.org/Profiling_with_AMD_CodeAnalyst

I must have missed that earlier. I've succesfully installed CodeAnalyst and added the symbols. I'll report back as soon as I've got more information.

In Bug 477852 (the similar bug report for Mac), it was confirmed today in comment16 that the whole browser is affected, not only video plugins. So it seems that several platforms suffer the same bug. (In reply to Bug 477852 comment7:) > This should be a high priority issue since most users watch YouTube and > the like on a daily basis. That was a severity description in the case of "only video player" problems. I would like to modify that sentence to point out the true severity of this bug as it destroys the whole visual behaviour of the whole browser. So: This should be a high priority issue since most users are likely to * scroll * write * click * see cursors * see animated GIFs * move the mouse pointer over the browser * use links * use the browser's user interface * switch between programs * move windows * watch movies on the web It IS that serious. The word "showstopper" is something that this kind of bug would be directly associated with in ANY commercial business.

(In reply to comment #59) > It IS that serious. The word "showstopper" is something that this kind of bug > would be directly associated with in ANY commercial business. Yes, and your comment is NOT HELPFUL. This is now the second time I need to drop a link to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html in this bug (see comment 39 for the last time). It's not like we aren't working on this bug, but it's not an issue that is universally seen by all. This is why we are asking for profiles (comment 39 again, but you clearly didn't bother reading it) to identify what the cause of the problem really is. We have instructions on how to profile on windows (comment 57), and I can point people to documentation for other platforms as needed. Comments like yours only waste developers time that could be spent actually fixing things, so please read the etiquette page and read the bug before you decide to comment in it next time. Thank you.

I'm not complaining about the lack of developer attention to this issue, I'm just trying to describe the bug better than the existing bug description with its "Importance: normal" and "Platform: x86 Windows XP". I've helped this bug report to reach the surface for half a year because I found it extremely important - not because I'm interested in software development - and I'll not be working on fixing it. Thank you for showing us what it means to be "wasting people's time" or whining (see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html ). I realize now that I had almost no idea what it meant in reality until just now. Goodbye.

Shawn Wilsher, I'd like the link to information on how to profile for Mac OS X as I've experience this bug and would like to help solve it (for the record, disabling the tab saving as outlined earlier seems to have solved the issue for me).

For OS X, you'll want to follow these instructions to get the right build: https://developer.mozilla.org/en/Profiling_JavaScript_with_Shark#Download_a_development_build And then you'll need to select "firefox-bin", and press start when you start to see the hang, and stop when it goes away. This isn't terribly scientific, sadly. You could also try to use spin control, but I have no experience with it. It may work better than shark, but you'd need those special builds. http://blog.mozilla.com/rob-sayre/2009/09/09/spincontrol/ may be helpful there.

Uhhh....wow, somehow I thought it would be a bit easier than this. I'll see if I can fumble my way through it.

I've just had a few tries at "capturing" the right moment with the profiler. As I'm not sure this is the right way to do it, let me briefly describe what I did: - Ran Minefield - Fired up the profiler when I noticed pauses - Made sure Minefields overall CPU usage was low so the spiked really stand out - Tried to start the profiling just before a pause, and stop it right after - Repeated that several times to create some data to compare against eachother - Also ran a few profile sessions where no pauses occurred So far this is what I notice when comparing the sessions: For the sessions with pauses: - On proces level, xul.dll leads the list every time by a large margin. Usually, around 40-50% timer samples. - It is followed by npswf32.dll with 10-20% timer samples. fyi; I had a paused Youtube movie in one of my windows. - On symbol level there are two processes drawing my attention: CS:EIP 0x716c09e7 / imgContainer::DrawFrameTo CS:EIP 0x712b20c0 / PL_DHashTableOperate Both lead the list with 10-20% timer samples. For the sessions without pauses: - xul.dll still leads the list, but with significantly less timer samples, between 25 and 30%. - npswf32.dll comes second with a little more timer samples, around 23%. - At the symbol level CS:EIP 0x716c09e7 / imgContainer::DrawFrameTo is still popular with 25-30% timer samples CS:EIP 0x712b20c0 / PL_DHashTableOperate only has around 0,25-0,40% timer samples In short: The most noticable difference is the amount of timer samples for CS:EIP 0x712b20c0 / PL_DHashTableOperate. There's a lot of them when Minefield pauses, and very little of them when no pauses occur. This is just a short first impression - I'll keep my Minefield running to see if the pauses become longer and then make a new set of sessions unless of course someone tells me I should do this differently. I reckon that, once I have a few good sessions I need to exported some of the data to file and post them here to be of any use? Could anyone give me a short hint on what exactly I should export?

(In reply to comment #65) > - On proces level, xul.dll leads the list every time by a large margin. > Usually, around 40-50% timer samples. This is probably expected. xul.dll contains almost all the native code that runs Firefox. > - It is followed by npswf32.dll with 10-20% timer samples. fyi; I had a paused > Youtube movie in one of my windows. This is flash, so it'll probably take a bunch of CPU if you have a video (it's still likely downloading the video even if it is paused). > - On symbol level there are two processes drawing my attention: > CS:EIP 0x716c09e7 / imgContainer::DrawFrameTo cc'ing a developer who might be able to provide more information on this method > CS:EIP 0x712b20c0 / PL_DHashTableOperate I'd need to see more of the stack - this function is used in lots of code. > I reckon that, once I have a few good sessions I need to exported some of the > data to file and post them here to be of any use? Could anyone give me a short > hint on what exactly I should export? When you try to quit shark, it'll ask you if you want to save. If you can upload that file, I'd be happy to take a look at it.

Martijn, knowing the full set of call stacks ending in these places would help. I think CodeAnalyst can do that. PL_DHashTableOperate is used wherever we use hash tables; it is epecially helpful to know the full call stack there. imgContainer::DrawFrameTo is used in all animated images. What might very well be happening there is the throbber painting, which would implicate bug 437829 for at least some of the time spent.

(In reply to comment #46) > I notice some improvement, not very spectacular however: > - it seems to take a little longer for the pauses to appear. Minefield is now > running for 6 or 7 hours and memory consumption is at 620 MB for the last 15 > minutes according to the task manager. I'm using 6 windows currently. > - the pauses seem a little bit shorter. > > The pauses are still very noticable though. I can still see CPU-usage spikes up > to around 50%, about every 20 seconds, exactly when a pause occurs. Strange. I got none of this, and was running two windows, both containing at least 12-15 tabs.

Thanks Joe and Shawn. This morning I was able to get a better catch of the pauses. I made three profiles with a pause and three without. CodeAnalyst only seems to allow exporting to CSV, I've included a attachment with those files. Concerning imgContainer::DrawFrameTo, I had about 15 animated GIFs in my active window to time/spot the pauses but they where small (smileys) with less than 10 frames, size about 30x15px / 2 KB each. While profiling this morning something else caught my eye at the top of the list: CS:EIP 0x712b24c0 / GCGraphBuilder::NoteXPCOMChild It was a very consistent 2nd in the list after PL_DHashTableOperate in the three profiles included in the attachment. I didn't have anything special open at the time except for the page with smileys. Just some static pages without video or anything. Hope this helps. Let me know if more info is needed.

(In reply to comment #69) > AMD CodeAnalyst data sets in CSV, with and without pauses I'm finding the CSV output to be not so useful. I can't tell if you've expanded stacks or not, sadly. A screenshot like https://developer.mozilla.org/@api/deki/files/3787/=codeanalyst8.PNG but with the stacks expanded may be more useful. > CS:EIP 0x712b24c0 / GCGraphBuilder::NoteXPCOMChild That looks like it's GC related, which is what I was afraid of (comment 29). cc'ing some folks who might be of use in that area too.

Yeah, unfortunately the CSV output isn't too helpful. :( I need some way of visualizing the tree, like the screenshot that Shawn posted.

Martijn, I don't see NoteXPCOMChild in the CSVs from comment 69... I'd also love to know something about the callstack there, or at least the caller. NoteXPCOMChild is cycle collection, but that should be pretty cheap for visible documents.

Happy to supply those screenshots. I could find a better way to export from AMD CA.

OK, that's definitely showing cycle collection (at least 11.34 + 7.49 + 5.26 + 3.04 + 2.63 == ~30%, and that's assuming the hashtable ops aren't cycle collection too; if they are, that's another 22% right there). The expansion there just says where the time is spent inside the function; I'd really prefer to see who's calling into NoteXPCOMChild (and fear it's nsGenericElement::cycleCollection::Traverse) and into PL_DHashTableOperate (I bet it's cycle collection, though). Shaver claims that CodeAnalyst can show callstacks and that the help talks about it... Martijn, you're just browsing, right? Nothing in particular that triggers this reliably?

I will dig into that to provide more information. I misunderstood what you meant with callstack ;-) I needed to restart Windows after installing AMD CA and since then I've kept an eye on things that I thought could trigger the pauses, but I didn't find anything out of the ordinary. The pauses seem to be very slight at first and then get a bit longer and noticable later on. Also, on this clean (except for flash plugin) and unmodified Minefield, the peaks seem to come every 20 seconds, or very near to that. Perhaps this brings to mind certain processes? Is cycle collection done every 20 seconds?

> then get a bit longer and noticable later on. Does this perchance happen to correspond to growing memory usage? > Is cycle collection done every 20 seconds? 160 // Cycle collector is never called more often than every NS_MIN_CC_INTERVAL 161 // milliseconds. Exceptions are low memory situation and memory pressure 162 // notification. 163 #define NS_MIN_CC_INTERVAL 10000 // ms But what actually triggers CC is complicated and depends on whether the user is interacting with the browser (e.g. moving the mouse), whether pages are being loaded/unloaded, etc, etc. So happening every 20 seconds is at least possible.

And if nothing happens in the browser (so that there are no new suspected objects), cycle collection doesn't run at all.

Btw, last time I profiled cycle collection, it was JS garbage collection which was taking most of the time. But perhaps it was just the testcase I was using. What are the "steps to reproduce" for this bug. Exact steps please, if possible.

I don't think anyone has discovered a set of steps that will reliably trigger the "really bad" mode of this issue. I'd say the freezes are not just "it happens" or "it doesn't happen" but rather they can occur less frequently and be of shorter duration, or more frequently and be longer. The steps below get my Firefox 3.5 to start exhibiting the freezes every 30 seconds or so, and each freeze is only just noticeable, perhaps 0.2-0.3 seconds. 1. Run several memory-hungry apps on the machine. VirtualBox might be an easy way to consume lots of RAM in the absense of a specialized tool. 2. Open a couple of Firefox windows, with 15 tabs each. 3. Navigate a lot in lots of tabs. I've tried three links in each tab, each window. I feel this helps trigger the issue. Verify that this worked by expanding the File menu and holding the right arrow. Firefox will start scrolling through all top-level menus. The freezes should be observable when one of the menus briefly stays longer than the others.

Boris: when I noticed the pauses, Minefield did have quite some memory usage. I have mentioned the Firefox 3.5.x memory usage in some of my earlier comments. Minefield currently uses 650 MB of memory with 6 windows open. Closing some of these windows doesn't lower the memory usage last time I tested. The windows contain nothing out of the ordinary; one for gmail, one for xmarks, phpMyAdmin, a IMDb page, phpBB3 page. My steps to reproduce are: 1. Install Minefield 2. Create new profile, and switch to that profile 3. Start minefield 4. Browse, browse, browse I usually keep one or more windows open at all times because they have articles I want to read or movies I want to watch. When I go to sleep I usually leave up to 4 windows open and then continue browsing the next day. 5. Repeat step 4 until pauses occur, mostly it takes a few hours. Last few days I didn't do anything that really put pressure on this machine. I ran Minefield. Had Thunderbird open alongside it, a few file explorer windows, notepad, SmartFTP, UltraEdit, Task manager and the profiler. That's about it.

It really sounds like something is leaking memory and then you end up with bigger and bigger object graphs that are still referenced but no longer in live documents for cycle collection to walk over... Just to cover all the bases, would you be willing to see whether there's a particular extension you have installed (from the list in comment 5, presumably) which triggers the behavior? I'll also try to browse a bit with those extensions and see whether I hit memory leaks...

(In reply to comment #78) You can use the steps to reproduce from comment #80, but I'll modify step 4 a little bit: 4. Browse pages with lots of flash, high quality animated GIFs and large images. Keep many tabs open. Keep browsing until you see lags/pauses. Pages with flash: Youtube, Vimeo, Hulu,... Pages with large images: Google Image Search > large images > click on the thumbnails; Also, search for "wallpapers" Pages with animated GIFs: http://www.hitarek.net/ http://dmfull.com/ http://www.dewa.com/animated/ http://www.animated-gifs.eu/ http://www.colectiva.tv/wordpress/lang/es-es/category/animated-gif/

First off. 1 - thanks to those who spent time to debug this, it seems after I last posted you guys made some progress. 2 - in reference to the devs, if they deliberatly dont mark as confirmed because people are getting frustrated then that is somewhat childish and will only make the matter worse. My own update is I disabled flash compltely in FF now, disabled the plugin so now on flash content I get the message saying I need to install the plugin. This seems to have improved things but the pauses are still evident, I may try a 3.6 nightly build and see how that changes things for myself. I agree with the comments as well in regards to the severity of this bug, pauses when scrolling pages and watching videos is a extreme issue, it means I have reverted to using other browsers (IE and opera) for various stuff now and using firefox minimally. GC does make sense since there would be less GC activity when less tabs are open. So this bug it seems is caused possibly by the idea that FF 3.x is to have less memory usage so is a side affect of the aim to reduce memory usage? My suggestion is for FF to do no automated GC unless a low memory flag is set in the options for people running on low spec machines, when this flag is unset the GC should only run when a tab or window is closed.

(In reply to comment #81) > It really sounds like something is leaking memory and then you end up with > bigger and bigger object graphs that are still referenced but no longer in > live documents for cycle collection to walk over... A memory leak is one of the scenario's I've been thinking about. When I was still running a stable version (FF 3.5.3 i believe) the problem appeared when memory usage was around 450 MB. In Minefield it seemed to take a bit longer to create the pauses, currently Minefield is using about 650+ MB. In earlier tests, I tried to crank up Minefields memory usage right from the start by watching a lot of youtube movies at the same time, opening some myspace profile with a packed music player, things like that. That way, I could get Minefield to use 600-700 MB of memory in a few minutes but the pauses didn't appear to me then. It was only a few hours after that while doing normal browsing that they actually appeared. And in case you're wondering: Minefield has been running for about 33 hours, CPU Time is 5 hours 51 mins. > Just to cover all the bases, would you be willing to see whether there's a > particular extension you have installed (from the list in comment 5, > presumably) which triggers the behavior? I'll also try to browse a bit with > those extensions and see whether I hit memory leaks... My current Minefield (profile) is without any extensions, I did install a few plugins because without them browsing is difficult for me. Those plugins are: 2007 Microsoft Office plugin (disabled) Adobe Acrobat plugin Windows Media Player plugin Shockwave plugin Silverlight plugin My normal browser behaviour doesn't really include pages with large animated gifs or lots of pictures. I do visit youtube quite a bit and usually watch their HD-quality movies. I will do my best to get the callstack info here before the end of this week. I've found the help page for that, but can't find the actual option to switch on. I need to dig a little deeper to get it working.

I played http://sandbox.headweb.com/sv/159766/filmer/pan-360-framebuffer-fail/ under Firefox 3.5.3 since it never fails to reproduce this bug on my Win 7 x64 machine. I was running in Safe Mode to avoid any pollution by add-ons. Clean.png depicts the Code Analyst profile view when I was doing nothing in the browser with two tabs open: one this bug page and the other one the video above, but not playing. Then I started playing the video and it started stuttering with pauses of around 4-5 secs each (great for profiling, I guess). I took two profiles (skippy1.png and skippy2.png). I am running FF with a fairly clean profile since I reinstalled my machine just a few days ago. If there's anything else I can help with, let me know. Thanks for working on resolving this.

I'm afraid that, without call stacks from those top symbols, there's not much we can do :(

> My current Minefield (profile) is without any extensions So no xmarks installed (I assume the windows in comment 80 were in 3.5, then)? Can you perhaps install https://addons.mozilla.org/en-US/firefox/addon/2490 and see whether it tells you anything interesting in your daily browsing?

Is the symbol server configured? Call stacks are supported by the most recent CodeAnalyst, though you have to hit this odd-looking "CSS" button when you're in the process tab, and your profiling session needs to be configured to capture call stacks on every timer event if you don't want to smash your face on the curb when you realize why the trace looks so weird. Or so I have heard.

Boris: in comment 80 I meant the xmarks website, not the extension. I use the site so I can still use some of my bookmarks without installing the extension. Leak monitor: I'll try. Mike: symbol server is configured, just as explained in the Profiling with AMD CodeAnalyst guide and it's working afaik because when opening xul.dll in AMD CA the first time it starts downloading the symbol data (and cache it in the directory I set up). The CSS button: I see it on the processes tab, but it's greyed out. I've set up the profile exactly as outlined in this guide mentioned earlier in this thread, getting the latest version 2.94: https://developer.mozilla.org/Profiling_with_AMD_CodeAnalyst The option also appears to be greyed out in the screenshots there, so at least that is consistent ;-) I will re-read the help page for Callstack Sampling later on. It mentions setting the option in Tools > Session Settings but I didn't see any CSS settings in the very short time I've spend on finding it. Would appreciate pointers to speed up the proces when I continue this today or tomorrow :-)

Oh, yeah. You need to go into Session Settings dialog, Show Options, click "Call Stack Sampling", and then set the Call Stack Interval to 1. I keep meaning to add a screenshot for that to the wiki, sorry!

I don't have Show Options button in the Session Settings dialog although I saw in the help file that it should be there. Could it be disabled on Windows 7, or there's something else to enable before that?

(In reply to comment #91) > I don't have Show Options button in the Session Settings dialog although I saw > in the help file that it should be there. Could it be disabled on Windows 7, > or there's something else to enable before that? I had the same problem. Also, in Session Settings the "edit" button was missing. It's also missing in the AMD CA guide so I didn't notice it at first, but it does show in the AMD CA help pages on Call Stack Sampling. It's probably because AMD CA is in express mode. Switching it to "normal mode" and then accessing the Session Settings dialog will give you some more options. Unfortunately, Call Stack Sampling is greyed out here (see attached). Perhaps we should take our conversation somewhere else to sort out the details on how to do a proper profile and then return here to post the data?

I managed to get CSS working (look below for details). You'll find xul_browsing.png and xul_video.png which depict the situation with Google/MSN open and playing the "framebuffer fail" video (see Comment #16). I hope that helps. @Martijn and anyone interested: I am posting steps to get Call stack enabled in Code Analyst since I think it's of importance for anyone who's interested in contributing to this report. 1) Open Code Analyst 2) Create a new project 3) Enter a project name and press OK in the New Project Properties dialog 4) In Session Settings: * choose Time-based profile from the list. * in the launch box, browse to your Firefox installation folder * click Show options * Check Call Stack Sampling * I also checked Stop data collection when the app exits * press OK 5) Click the 'Play' button in the toolbar, which starts Firefox and starts profiling immediately.

Unfortunately, those steps do enable me to check Call Stack Sampling, but in the processes tab the CSS button is still greyed out. I did notice that AMD CA also collects info on a "ASM" tab which contains Address, Code Bytes, ASM Instruction, Symbol and timer samples. In the mean time, my Minefield was idle for the better part of the day with just one or two windows open. CPU Time now wat 7h 16m, memory usage 850 MB. The pauses are more noticable now, as they are a bit longer. Most appear with 20 second intervals, although I just spotted a 60 second interval while typing this message. According to the graphs in task manager, the CPU now peaks at 100% at every pause. Fyi; Profiling again showed PL_DHashTableOperate on #1 with 21% of the samples, followed by GCGraphBuilder::NoteXPCOMChild with 10%. Third is nsGenericElement::cycleCollection::Traverse with 6.5%. (I know it's not worth much without Call Stack data, but it's clear that these are consistently showing up) I'll restart my Minefield now so I can install the Leak Monitor extension. It might take a while for me to recreate the pauses as I experience them now.

After running a while with the Leak Monitor extension installed, I've received no warnings whatsoever, even when the pauses where very obvious.

Hmm. Comment 94 really does sound like you're ending up effectively leaking a bunch of stuff... David, any idea what we could try here?

Was anyone able to do something with the call stack data from comment #93? Krylko, does your process tab and PID tab show the same as mine after capturing a pause? (PL_DHashTableOperate on #1?) Fyi; I have now heard from 4 different people that they are experiencing the same pause across different platforms. All do have the same browsing behaviour: either a lot of windows or a lot of tabs, and leaving FF open for longer periods of time.

(In reply to comment #97) > Was anyone able to do something with the call stack data from comment #93? > Krylko, does your process tab and PID tab show the same as mine after capturing > a pause? (PL_DHashTableOperate on #1?) I think we've established that this a garbage collection pause that folks are seeing. What we are trying to find out now is why you have so many objects allocated because that is unexpected. Boris thinks this is a leak (per comment 96), but we are waiting for dbaron to give us some other ideas on figuring out what might be leaking.

(In reply to comment #81) > It really sounds like something is leaking memory and then you end up with > bigger and bigger object graphs that are still referenced but no longer in live > documents for cycle collection to walk over... An alternative explanation would be that he has a page open that is accumulating large numbers of still-reachable elements that have been removed from the document. That seems more consistent with leak-monitor being quiet (assuming it's working at all... maybe worth trying the "adding an observer and not removing it test in http://dbaron.org/mozilla/leak-monitor/#testcases ; it just involves entering about:config in the URL bar and then entering a javascript: URL in the URL bar). Are any pages being kept open for long periods of time? Which?

David, sorry for not getting back to you earlier. I can have all sorts of pages open for longer periodes of time. Youtube usually is among the pages that are open for a long time, but sometimes it's just an plain HTML article or forum thread I'm (planning on) reading. I've installed Leak Monitor on my "normal" Firefox, v3.5.4, on my normal profile. Immediately after FF restarted it re-opened all my six windows plus a Leak Monitor window with a very long list of (suspected?) leaks from a site I visit daily. It's unclear to me why I didn't get this popup while testing/surfing the the nightly. I will report the leak to them as soon as I encounter it again. Also tried the "adding an observer" trick and indeed got a window reporting a leak on that.

> I will report the leak to them as soon as I encounter it again. It's probably better to report it to us, since they shouldn't be able to cause leaks to start with with JS code. I'm hoping this is a public site...

It is a public site. http://tweakers.net. I get a total of 5 new leak alerts. All appear at once when visiting http://tweakers.net. I don't need to be logged in to reproduce. 1. A long list of leak alerts for http://tweakimg.net/x/min/general.js. See attached. 2. Leaks in window 0x8511be0: [ ] [leaked object] (8511be0) = [ChromeWindow] 3. Leaks in window 0x940c4e0: [ ] [leaked object] (940c4e0) = [Window] 4. Leaks in window 0xaf61c80: [ ] [leaked object] (af61c80) = [Window] 5. Long list with chrome:// urls. See attached.

Mh, I'm now getting alerts on Youtube javascript as well. Let me create a clean profile before giving you any more information. These alerts didn't appear to me when using the nightlies and I do have several extension installed on this particular profile.

I have been using the 3.6 beta for a while and the problem was noticebly improved, however since RC1 of 3.6 the problem is as bad as it was in 3.5.x. :( So I wonder what changed between the last beta and RC1.

I have just installed the leak monitor, I got a popup immediatly after the restart. Leaks in window 0x234b49e0: [ ] [leaked object] (234b49e0) = [Window] then after moving the mouse another appeared. Leaks in window 0xce74960: [ ] [leaked object] (ce74960) = [Window] a 3rd Leaks in window 0x510e0c0: [ ] [leaked object] (510e0c0) = [Window] then 2 empty reclaimed leak alert windows

I am getting quite a lot of popups, but from reading the description it would seem I am only supposed to see them when closing windows. I get popups simply from browsing various websites, they also seem random, I can get a popup for a particular url but if I revisit the page a 2nd time there is no popup. One site that gives me a lot of popups is forums.thinkbroadband.com/js/jquery-1.3.2.js but most sites are giving me one just less frequently.

another one for refreshing this page. Leaks in window 0xc1b5240: [ ] [leaked object] (c1b5240) = [Window] [ ] [leaked object] (123e8460, https://bugzilla.mozilla.org/js/yui/yahoo-dom-event.js, 8-8) = [Function]

It has been quiet on this bug for a while. Perhaps one of the developers could summarize what info is needed for a real breakthrough in this bughunt. This all has become quite a long conversation and a summary may motivate some people to do some hunting themselves. @Chris: Thank you for your efforts on helping with this hard to catch problem. LeakMonitor can give some clues as to what's causing the resources to leak however I believe it's important that LeakMonitor is used on a clean profile to distinguish between leaks in Firefox itself or leaks caused by add-ons. You'll find info on creating a new profile here: http://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile If you already are on a clean profile then discard my comment ;-)

Chris, you can find daily builds between the 3.6 beta and 3.6 rc at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (in the directories whose names end with "1.9.2"). Would you be willing to try doing a binary search on those nightlies to see when the problem reappeared for you?

I installed FF 3.6 and it's basically the same thing with Flash (like I reported before). What surprised me is that the HTML5 demo video http://www.dailymotion.com/openvideodemo behaves the same (hiccups here and there). I think now that it definitely has to do with I/O because as soon as the hard drive activity increases, the hiccups start occurring. I thought Flash had at least something to do with the problem, but the video above cleared the doubt.

Do videos go through the disk cache? If so, you might be helped out a lot by bug 513074

(In reply to comment #110) FWIW: I also tested http://www.dailymotion.com/openvideodemo on Fx 3.6 final. The first time it played almost flawlessly. Then, I played with the effects on the left column and mayhem ensued.

Well my data point here: FF -> 3.5.6 Flash -> 10.0.42.34 I am testing with some time lapse YouTube videos since the pans show up the stutters particularly well, e.g.: http://www.youtube.com/watch?v=_xMz2SnSWS4 I am getting stutters almost exactly every 5 seconds. Even though this didn't seem to match with with session restore suggestion I set: browser.sessionstore.interval = 120000 without any result. I also switched to the TabMixPlus session restore without any effect. I then tried: browser.cache.memory.capacity =120000 which has been suggested to try at least 80000. Again no effect. All tested videos play perfectly smooth in IE8.

It is my belief that this bug happens to everyone who leaves many (30+?) tabs open for a long time, at least a few hours. I wish I had the technical skill to help. My computer is rather fast and has loads of memory, but I still experience the hang-ups and stutters. What surprises me most is that CPU and memory usage by FF are never very high on my computer when this bug happens: why would FF stutter when I have plenty of CPU power and memory left? Well, perhaps every already knew this. Good luck on fixing this, whoever can do it; I'd be overjoyed if it worked.

I can only confirm: very annoying stutter every few seconds Flash animations/videos hang for a little while. Allo page scrolls and other browser functions seem to hang for the moment. Then it starts playing again and hangs after a few moments again. Hiccups also noticable on http://www.dailymotion.com/openvideodemo. Anyway - I cannot correlate this with the number of tabs opened or how long Firefox was on. Windows 7 x64 Ultimate / FF 3.6.3 The problem does not affect IE - by the way.

I can confirm too, and just hope that this can be fixed as it's driven me nuts for a long time! I'm on OS X 10.5 using FF 3.6.3, and I notice videos stuttering every 3-4 seconds. One interesting thing is that when I run 'top', I see a 'stuck' process listed for a split second roughly around the time of the stutters... I was blaming it on Flash, but the http://www.dailymotion.com/openvideodemo video is HTML5 and I see it there too! I'm one of those people who has 30-40 tabs open for days at a time as reference material, if that makes a difference. Thanks for looking into this!!

I managed to fix this bug by installing Chrome. (Sorry)

Firefox 3.6.3plugin1 (Lorentz test build with out-of-process plugins) with Flash 10.1 RC (hardware-accelerated h.264 playback on Windows) seemed to clear this up pretty well for me.

(In reply to comment #118) > Firefox 3.6.3plugin1 (Lorentz test build with out-of-process plugins) with > Flash 10.1 RC (hardware-accelerated h.264 playback on Windows) seemed to clear > this up pretty well for me. Did that also remove the halting problems also for animated GIFs, scrolling, menus, text cursors, and the browser's general graphics updating? Flash has been mentioned a number of times recently, but is it really relevant? If Flash stutters, but the browser graphics and animations like http://www.emoticones.com/emoticonos_bananas.php do not, then I believe it's another problem. Another point of view, regarding this bug and memory leaks: I always see the memory consumption grow over time, and the stuttering is never apparent while memory consumption is low. After some day in use, the Firefox process typically takes 700-800 MB of memory, several % of CPU load more than initially, and the stuttering is always there. Memory consumption increases even if I have the same number of tabs open, and even if I don't watch a lot of YouTube movies or other memory-intensive webpages. At the minimum I have a Facebook tab open constantly, and occasional other tabs open for a while, and the memory just increases and increases. What on earth is eating all these enormous amounts of memory?!? Are there any bug reports related to memory leaks that someone should connect to this bug and raise the priority in order to get some progress? For me there seems to be an obvious connection, but I'm not one of the developers - I'm just an exceptionally slow-moving user within one inch from installing Chrome.

(In reply to comment #119) > Did that also remove the halting problems also for animated GIFs, scrolling, > menus, text cursors, and the browser's general graphics updating? No, unfortunately, just Flash videos. (However, at least for me, that's where the issue was most annoying. General performance in 3.6 is not as bad as it was in 3.5.) And I'm not completely satisfied that it's fixed there [Flash videos] yet since I've only been running this configuration for a couple of days, but it seems way better than it used to be so far. (I am also a heavy user with many tabs open for days. :-P)

(In reply to comment #119) > (In reply to comment #118) > > Firefox 3.6.3plugin1 (Lorentz test build with out-of-process plugins) with > > Flash 10.1 RC (hardware-accelerated h.264 playback on Windows) seemed to clear > > this up pretty well for me. > Did that also remove the halting problems also for animated GIFs, scrolling, > menus, text cursors, and the browser's general graphics updating? > Flash has been mentioned a number of times recently, but is it really relevant? > If Flash stutters, but the browser graphics and animations like > http://www.emoticones.com/emoticonos_bananas.php > do not, then I believe it's another problem. For me on the normal FF 3.6, I see the stuttering every 3-4 seconds on Flash the worst (using 10.1RC), it's noticeable on the HTML5 video but not as bad, and I can't notice anything on the 'dancing bananas' GIF page.

To all victims of this bug: I worked around this issue by using the BarTab extension. https://addons.mozilla.org/en-US/firefox/addon/67651/ This allows me to keep my excessive number of tabs "open" for reference, but they load on demand. Is there some equivalent of Chrome's Task Manager for Firefox, that would allow me to blame particular page/tab for excessive resource consumption?

I'm too still suffering this issue on 3.6.3. It would be great if a summary of how to assist devs in fixing this was made... preferably something where we don't have to create clean profiles and whatnot.

If we assume that the jerkiness is the result of garbage-collection pauses (which seems likely, but is probably worth verifying, though I'm not sure how I'd go about that in a non-debug build), then, I'd note that: (1) the JS group has a bunch of plans for making GC pauses much less of an issue (I don't know the details) (2) increasingly long GC pauses usually happen when the GC heap gets large. This often results from memory leaks (either in Gecko or in websites, or some combination of the two), or could result from just having a very large number of pages loaded. (Leaks in websites are more of an issue when a single page is open for a long time; then the site has more of a chance to accumulate lots of objects in memory.) We've had a bit of discussion of better memory debugging tools as well, but I don't have any immediate news to offer there.

(In reply to comment #124) > If we assume that the jerkiness is the result of garbage-collection pauses > (which seems likely, but is probably worth verifying, though I'm not sure how > I'd go about that in a non-debug build), then, I'd note that: > > (1) the JS group has a bunch of plans for making GC pauses much less of an > issue (I don't know the details) See bug 558861. > (2) increasingly long GC pauses usually happen when the GC heap gets large. > This often results from memory leaks (either in Gecko or in websites, or some > combination of the two), or could result from just having a very large number > of pages loaded. (Leaks in websites are more of an issue when a single page is > open for a long time; then the site has more of a chance to accumulate lots of > objects in memory.) Add-ons can induce leaks too. Anyone noticed a common add-on factor? Just asking. > We've had a bit of discussion of better memory debugging tools as well, but I > don't have any immediate news to offer there. Bug 551477 is moving now -- looks promising. /be

With the performance-monitor tools in Windows 7 and Vista, you can look for I/O spikes that correlate to the jerkiness you see, or Firefox CPU spikes. Those would point at some different possibilities. Some of these things are already materially better on the trunk, so if people could say if things are better/worse/same with 3.7a4 or a nightly there, it would also be helpful. (Or with 3.6.4 betas, which have us lockstepping a lot less with Flash.) I think this bug is summarizing a pretty wide range of problems, which are likely going to need a bunch of different solutions or mitigations (links-stop-responding vs video-is-jerky are probably quite different, at a guess), but we can spin out for more detailed bugs as we identify more specific cases.

I should note that for the one person who did profile his hangs the time was basically cycle collector.

This is so sorrow. I am now 100% convinced to switch to Chrome at the moment. Video freezing is so annoying it renders the browser pointless today when video content is so popular. I hoped you can do something about the bug but is is now so obvious FF developers have no idea what to do to get rid of it and they pretend it's a minor bug. Nope my friend - this is a MAJOR ISSUE and you need to relaize that. If you do not - FF is dead. For me it's caput already right now. Welcome Google Chrome.

to those who think its a multitude of different issues I disagree. I strongly believe its one bug which has a multiple of different symptons and I see a relation with having more tabs open. The bartab addon looks like it could be a great workaround and I plan to install it after this post. To repeat for those who see this recently and dont want to read everything. FF basically stalls every so often, usually every XX amount of seconds, this stall will affect scrolling, animated images, typing text in a box like this, flash videos, flash animations. When the stall happens cpu is not saturated and seems GC is the most likely cause as GC is something that will be heavier when more tabs are open. Every so often the problem gets worse and I then notice I have let the number of idle tabs get high and close a few and the problem then eases again, tabs with flash videos do tend to be particurly bad but they are not the specific cause. Also I would like to be convinced as to why FF needs to store data automatically every so often as if its fearing an imminent power cut or something, especially as it uses sql format which is more i/o intensive than a basic text file.

Cut the chatter. No one said there are a "multitude" of different issues; shaver suggested that two different symptoms probably didn't have the same cause. This bug is real and it will be fixed. As bz pointed out, the Cycle Collector is implicated here, and it will get fixes started by Andreas (see bug 547941) for Firefox 4. So, have some hope, or if you lose hope, have the good grace to avoid spamming this bug with rants. Those just get in the way of people trying to fix the bug. /be

Cycle collection seems to be one of the major causes of the lag people report here. bz's profiles confirm that. bug 565217 will try to address that problem. If you have an easy way to reproduce this issue, it would help if you can describe it in that bug so we can build a test case.

Good news, bartab seems to at least partially resolve the problem and be a good workaround. I have no noticeable stalls now, another stall that is gone is often when FF was left idle, when I first scrolled it would stutter as if coming out of an idle mode. That is also resolved. This is only after short use tho, if my symptons come back I will update again. To the guy who says I am ranting, I was providing feedback nothing more. Good news on the 4.0 planned as well, although I read it may be in 3.7?

Chris, I think Brendan's "ranting" comments were about comment 128, not your comment.

Chris, 3.7 = 4.0 Thanks to the devs and other interested parties for providing links to the related bugs. I will be very happy to see some of these changes implemented. I have anecdotal evidence that this bug is related to garbage collection and memory handling. I have about 4 instances of FF that I have "maintained" over the years, each with different configurations and uses (work PC, school/laptop, HTPC, girlfriends' laptop). The common element of this bug (and it has occurred in all of these environments) is memory usage. This leads me to agree that garbage collection is the culprit. On my main installation, I typically have 100+ tabs open and notice this bug the most. It affects all areas of the UI/page indiscriminately. Typically, if I restore a session with cleared cache/etc with this many tabs, memory will quickly jump to about 80% of the 'steady-state,' then slowly rise until it hits that mark (around 800MB). The problem is present from the beginning but becomes worse once it hits that steady-state of memory use. No changes in CPU usage are correlated with the rendering pauses. Thanks to Bar Tab (amazing extension) this issue is mostly resolved for me. With that and a few config tweaks my memory rests around 450MB now, and I still notices occasional pauses, but they are very infrequent compared to before.

The best website to describe the problem is probably the Javascript speedup description page that was created to outline the differences between 3.5 and 3.6. See http://hacks.mozilla.org/2010/01/javascript-speedups-in-firefox-3-6/ Running the "spinning dial" animation behaves EXACTLY as the unresponsiveness (typing, mouse events, flash, GIF animations etc.) described in in the previous comments. As some have pointed out, the short periods of unresponsiveness appear to coincide with the garbage collection process. Running the same "spinning dial" in Chrome gives me a completely smooth animation while I get up to 100ms delays and visible jerkiness in the dial in Fx 3.6 with just a few tabs open. I have 8gb of ram on a W7 Core2 Quad Q9550 machine. From my point of view this page is the easiest way to consistently reproduce and visualize the problem and hopefully can help developers addressing the problem. I take it "fixing" garbage/cycle collection is not a trivial task as us users would think, maybe Andreas could (in layman terms) give some background on https://bugzilla.mozilla.org/show_bug.cgi?id=565217 -- would an interruptable CC fix the unresponsiveness described here?

In brief, the work for Firefox 4 that should fix this bug consists of 1. Making cycle collector interruptible (bug 565217), so it never can yield rather than take too long in any run, and pick up where it left off (or if need be start over). Cycles do not form fast enough to need frequent runs, but currently CC and JS GC are intertwined and must run to completion. 2. Breaking the GC heap up into compartments, bug 558861. This helps because some GC runs spend most of their time marking live objects. 3. Other GCs find much garbage and spend most of the GC's runtime finalizing compared to marking, so we're working on speeding up finalization too. See bug 556133. /be

(In reply to comment #136) > In brief, the work for Firefox 4 that should fix this bug consists of > > 1. Making cycle collector interruptible (bug 565217), so it never can yield Oops, strike that "never", of course :-P. > rather than take too long in any run, and pick up where it left off (or if need > be start over). Cycles do not form fast enough to need frequent runs, but > currently CC and JS GC are intertwined and must run to completion. > > 2. Breaking the GC heap up into compartments, bug 558861. This helps because > some GC runs spend most of their time marking live objects. And with compartments we can run GC only on active tabs' compartments, and in general schedule GC to happen only where garbage could be piling up. Mostly live compartments where script hasn't done anything that might make garbage can be left untouched. This should be a big improvement on the clock demo. /be

(In reply to comment #134) > On my main installation, I typically have 100+ tabs open and notice this bug > the most. It affects all areas of the UI/page indiscriminately. Typically, if I > restore a session with cleared cache/etc with this many tabs, memory will > quickly jump to about 80% of the 'steady-state,' then slowly rise until it hits > that mark (around 800MB). The problem is present from the beginning but becomes > worse once it hits that steady-state of memory use. No changes in CPU usage are > correlated with the rendering pauses. Aren't they? I clearly see CPU peaks at the pauses. (Using Windows Task Manager with Update Speed = High.) Firefox starts on around 100MB of memory, rising to around 300 MB within a couple of hours of use - even with just a Facebook tab loaded constantly, with occasional other tabs opened and closed again. Then the pauses are starting to get annoying. Some hour later, around 400 MB, the pauses are 3 seconds. The laptop fan also keeps running, due to several percent CPU use. (I don't often watch web movie clips, but if I do, I prefer to turn to MSIE to get a decent UI flow, which is a bit of a scandal.) After a day of use, around 600 MB, the behaviour is extremely bad, and even the sound buffer is not enough anymore - both video and sound have glitches. I rarely reach above 800 MB without Firefox crashing. The higher the memory usage, the more prominent the peaks, and the more heavy the CPU consumption. When started, Firefox eats under 5% CPU. After some hours it's over 30% instead, the fan stays on to cool things down, and I measure an increase from 21 watts to 23 watts of power consumed by my laptop. That's an increase with 10%! Imagine that all the many millions of Firefox users in the world typically consume 1 watt of power more than necessary just because of THIS BUG. That's several megawatts of power! A whole coal-fired powerplant, that shouldn't have to exist at all! It's not just a visual UI problem, it's much more severe. > Thanks to Bar Tab (amazing extension) this issue is mostly resolved for me. The Bar Tab extension is truly wonderful, now I can restart Firefox more often without regrets. On the other hand, the primary cause of loving Bar Tab is the Firefox bug... :-) Preventing all tabs to re-open is brilliant, but I haven't seen any use of "unloading" tabs with Bar Tab to avoid this bug's behaviour. > With that and a few config tweaks my memory rests around 450MB now, and I still > notices occasional pauses, but they are very infrequent compared to before. Interesting. How on earth did you manage to do that? What kind of config tweaks? Could some of them be published as more or less "recommended" workarounds for Firefox users in general, and could some of them even be included as standard Firefox settings until the bug is resolved? Every temporary solution is valuable here!

Firstly move to the latest build that you can handle without breaking all your extensions. I find that 3.6.4 (the latest version from the beta release page) has pretty good extension compatibility and has quite a few performance improvements. For instance, in previous versions I've always had problems with the javascript JIT functions causing excessive CPU usage and exacerbating this UI problem with even a moderate number of tabs open. Now I can enable JIT without noticing any significant CPU penalty on idle. So you may want to play with those options (just search 'jit' in about:config). I can't remember if you have to restart FF for them to take effect. I have bumped up the memory and disk cache limits, that may have helped with this specific problem but I'm not sure. Some other things that people have mentioned are adjusting browser.sessionhistory.max_total_viewers in the config, which caches pages in the back-forward history of tabs. Also, in the last couple months I have become pretty hooked on NoScript which I'm sure prevents quite a bit of unnecessary code being executed on my end.

Not going to block on a meta-bug, GC compartments and other improvements are scheduled individually.

Is this issue resolved in latest FF 4 builds?

I haven't had time to test in the FF 4 betas. Perhaps anyone else with experiences on this particular problem? From what I've heard the latest beta is not the best in user-experience for everyone (mainly slow on some parts?) because there's still a few things that need to be put together for the final release. Since people experience the bug described here mainly after long sessions of browsing, perhaps they run out of patience before encountering the problem.

I've had a chance to test Firefox 4 beta 6 over the last couple of days. After giving the browser a thorough shakedown and getting the memory usage up to 600 MB, I made sure I had several windows and tabs open for longer periods of time. This usually was enough to trigger the very noticable pauses in video. What I have discovered so far is that the pauses with an interval seem to be gone when playing video. I've tested this on several sites that use a player based on Flash, mainly YouTube and Vimeo. There where some pauses, I would classify them as "incidents". However, I also noticed that the problem with pauses on entering data in form fields is still there. The good news is I experience it as less of a problem than on FF3. The intervals between pauses are longer, the pauses occur less regular and they seem shorter as well. I haven't done any profiling but I do see CPU-usage spikes appearing exactly when FF4b6 pauses. Overall: beta 6 still has all kinds of quirks that interfere with the browsing experience and that may be a reason for you not to switch to it as your primary browser right now. But in my tests I experienced that some of the pauses listed in this bug are gone or less noticable. If you are still irritated by the pauses and are willing to give the beta a go dispite some other issues (perhaps help out with testing beta 6 in the mean time) then switching to beta 6 probably is a good step for you :-) Where not quite there yet, but its a good improvement.

(In reply to comment #143) > However, I also noticed that the problem with pauses on entering data in form > fields is still there. The good news is I experience it as less of a problem > than on FF3. The intervals between pauses are longer, the pauses occur less > regular and they seem shorter as well. I haven't done any profiling but I do > see CPU-usage spikes appearing exactly when FF4b6 pauses. So that is not something we were even thinking about in this bug AFAIK. Can you please file a different one for this issue please?

> (In reply to comment #143) > > However, I also noticed that the problem with pauses on entering data in form > > fields is still there. > So that is not something we were even thinking about in this bug AFAIK. Can > you please file a different one for this issue please? Isn't this all the same bug? Whatever you're doing - watching videos, scrolling a page, entering text in a data field, selecting an item in a web page menu - Firefox becomes unresponsive for a few seconds once you have a large number of tabs open.

(In reply to comment #145) > Isn't this all the same bug? Whatever you're doing - watching videos, scrolling > a page, entering text in a data field, selecting an item in a web page menu - > Firefox becomes unresponsive for a few seconds once you have a large number of > tabs open. I think that is specifically different from what we think most people are talking about here (maybe similar symptoms, but totally different cause).

Please don't focus too much on flash and videos. Duplicates of this bug have been delayed for ages since people thought it had with plug-ins to do, when it's actually the whole graphical updating that halts. Jerks in flash and videos can also be partly caused by increased CPU needs, while jerks in more basic functions surely ARE actual jerks. Why doesn't the page scroll directly? Why isn't my typed text shown directly? Why doesn't the mouse pointer and link texts change appearance directly? Why are animated GIFs halting? Why are menus and tab changes halting? THESE are the big issues to fix imho. This halting is directly connected to an ever increasing memory consumption and an ever increasing CPU usage. Why oh why do they appear? THESE are the big bugs to find imho.

(In reply to comment #147) > Please don't focus too much on flash and videos. Duplicates of this bug have > been delayed for ages since people thought it had with plug-ins to do, when > it's actually the whole graphical updating that halts. Jerks in flash and > videos can also be partly caused by increased CPU needs, while jerks in more > basic functions surely ARE actual jerks. > > Why doesn't the page scroll directly? Why isn't my typed text shown directly? > Why doesn't the mouse pointer and link texts change appearance directly? Why > are animated GIFs halting? Why are menus and tab changes halting? Exactly! It's all the same bug! Launch Firefox and everything is smooth. Open tabs, open more tabs, and EVERYTHING stutters and jerks. It is NOT confined to Flash/video. I think everyone in this thread had confirmed that. It is NOT only a Flash/video bug, it is Firefox-wide once you have a large number of tabs open. "BarTab" makes it less painful to quit and relaunch Firefox once the jerkiness becomes unbearable, but once you load the tabs the jerkiness comes back - the fact that BarTab can unload tabs after a length of time unfortunately does not prevent the jerkiness,

(In reply to comment #148) > Exactly! It's all the same bug! Launch Firefox and everything is smooth. Open > tabs, open more tabs, and EVERYTHING stutters and jerks. It is NOT confined to > Flash/video. I think everyone in this thread had confirmed that. It is NOT only > a Flash/video bug, it is Firefox-wide once you have a large number of tabs > open. I'll reiterate: same symptoms != same bug. I have a good idea about what could be the issue with the form field stuff, which is why I asked for a separate bug to be filed (it can block this one, but the work for it isn't going to happen here).

(In reply to comment #148) > Exactly! It's all the same bug! Launch Firefox and everything is smooth. > Open tabs, open more tabs, and EVERYTHING stutters and jerks. It's not even necessary to have more than one or two active tabs open, it will happen anyway after some hours of loading pages. FF just grows (CPU-wise and RAM-wise) and gets jerkier.

(In reply to comment #150) > (In reply to comment #148) > > Exactly! It's all the same bug! Launch Firefox and everything is smooth. > > Open tabs, open more tabs, and EVERYTHING stutters and jerks. > > It's not even necessary to have more than one or two active tabs open, it will > happen anyway after some hours of loading pages. FF just grows (CPU-wise and > RAM-wise) and gets jerkier. Guys, we have to work from symptoms back to diseases, effects back to causes. To do that it doesn't help to jump to any conclusions. One symptom could have many causes; you also can get more than one symptom from a primal cause. In mr's case I'd like to hear what plugins and addons he has installed, because that is not normal "small or new profile" behavior. Filing a new bug would help, even if we end up dup'ing it back here. Please be detailed about your browser's config. /be

@Brendan Eich You guy try to be too wise actually. You pretend this is kind of rare, unexpected FF behavior while I can tell you: I use Windows 7 x64 and many add-ons while my wife stayed with XP x32 and uses only a few addons and what? - We both experience this nasty jerky performance. My friend who use FF on Vista onhis notebook - same story. And you know what - unless a few brilliant add-on, especially AdBlockPlus and Zotero I would dump the entire FF to trash as I am fed up with this unsoluble problem completely ignored by developers who pretent it is non existent or very seldom phenomenon. Actually the developers hould focus on this issue as this is so annoying and frustrating that now I only use IE for videos and flash games. It is simply a nightmare to do it with FF. And how can you be proud with browser what cn grow up to 1.2 GB in memory usage just overnight ??? If that were Internet Explorer the whole community would ridicue it only because it is so fancy to laugh on MS. But actually - FF started tobe yet another **** on the market only being kept alive by add-ons developers! So, when I heard FF4 will have the same performance issues I started to think open sourcecomunity is perfectly replicating the biggest mistake of some commercial software producers who only kepp adding more and more pointless features and even more pointless interface changes but never bother to resolve fundamental bugs or quirks rendering entire application just **** - only bigger, more heavy one. And when I read your comments, Mr. Eich I feel like dealing with some corporate block who was trained to obscure discussion with stupid remarks like "that is not normal small or new profile behavior". Hi man - do us a favour and install FF on real environment, start using it like all of us normally do and you will see what is the problem yourself! That is not that difficult. And stop frustrate us with "small or new profiles" as nobody here is going to keep his/her computer in this state for ever only to satisfy your clockwise mind. Contrary to you - we are REAL users who actually USE their machines every day. And it is completely stupid to complain our machines' profiles are not enough "small or new" to be compatible with crapy code of FF core. - Jesus !!!

Now, everybody keep their shirt on, yelling at developers or at eachother won't help anyone. Solving problems just takes a lot of patience and trust in developers, and I have that confidence. But developers do need good pointers, because just crawling through code won't help them find the problem. And so far perhaps our pointers just haven't been accurate enough. I think that every Mozilla developer checking this thread realises this isn't just a very small problem. @Shawn: i'd be more than willing to open a new bug report for specifically the pausing of entering data in form fields if that'll help. Before I do that I want to point out that -although it isn't mentioned in the title- the pausing of entering data in form fields has been mentioned quite a few times. It is mentioned in the first comment and I have mentioned it myself several times throughout my comments. The reason they seem related is because in FF3, pausing of entering form field data occurs at the same time as the pausing of video, scrolling, animated GIFs, etc. Perhaps this is why "So that is not something we were even thinking about in this bug AFAIK." may have caused irritation for some of the users. Again, if someone is able to tell me what needs to be done to record very accurate data on what is causing this I'm open to advice.

Absurd, This is same problem - the "hang" is simultaneus: in a very same moment video hands, if you type in forms - it hangs too, scrolling hangs, tabbing hangs. And sometimes it hands for long enough that it's possible to see the peak in performance monitor. Splitting it into spearate "hangs" will not help solving the problem. There must be a good reason why FF suddenly absorbs so much processor power - some stupid close loop or whatever. No wonder that when some process peaks up to 80-90% of precessor power it becomes unresponsive!

(In reply to comment #153) > Before I do that I want to point out that -although it isn't mentioned in the > title- the pausing of entering data in form fields has been mentioned quite a > few times. > It is mentioned in the first comment and I have mentioned it myself several > times throughout my comments. The reason they seem related is because in FF3, > pausing of entering form field data occurs at the same time as the pausing of > video, scrolling, animated GIFs, etc. Sorry, but I'm just not seeing it. Looking at every instance of the word "form" in this bug, I see nothing about entering data into form fields until comment 143 (yours). I even re-read every single comment you've made just to make sure I didn't miss something. Comment 143 is the first one in which entering data into form fields was brought up. I don't think this criticism is warranted in this instance. I strongly suspect that what you brought up in comment 143 about entering text in form fields is related to disk I/O (80% sure), so using the tools shaver mentioned in comment 126 and looking at disk I/O would be a great start. However, we should pull this discussion into a new bug and people who aren't seeing it don't have to listen to us debate about it. :) I understand that this is an emotional issue for some people. We are serious about getting to the bottom of it, but it's not an issue that everyone sees. This makes it hard to reproduce for developers, which makes it hard for us to fix without getting valuable data from users (which folks have been providing in this bug and we are grateful for).

Zbigniew, I have the same problems, as you have: 1. FF memory sometimes grows uncontrollably (FF hangs completely when it reaches 1.5GB) 2. Periodic hiccups - video and forms Now, if your and your wife's machines both exhibit the same behaviour, can you please post the list of extensions, plug-ins and GreaseMonkey scripts that is common on both machines? If the problem is external to FF, we can try a process of elimination. If enough people participate, perhaps we can figure out if the problem is in FF itself or not. (That is, unless it is in a very common plug-in like ABP or NoScript.) Personally, I have a strong feeling the the problem is in the garbage collection but I don't even know how to check this assumption. And for whatever it is worth, I share Zbigniew's sentiment -- the plug-ins are the only reason I haven't dumped FF for Opera, Chrome or even (horros!) IE8.

(In reply to comment #156) > Personally, I have a strong feeling the the problem is in the garbage > collection but I don't even know how to check this assumption. And we've done a bunch of garbage collection work that will make Firefox 4 beta 7, but I don't have a bug number handy. I bet brendan or shaver do though.

I've used Firefox (3.0, 3.5, and 3.6) on Windows XP x86, Windows Vista x64, and Windows 7 x64 and I'd just like to add that this issue crops up in *all* of them. At least for me, the *entire* UI becomes unresponsive periodically and not just the browser content area. This includes native Windows Open/Save file dialogs, options screens, form entry, mouse cursor hover states, and any other aspect of the UI you can think of. Basically, it feels as if some big operation is happening on the UI thread periodically (the GC sounds plausible...). The funny thing is that the UI actions become queued up so that if I click multiple elements on the page during the freeze periods, they will get processed once the UI thread becomes responsive again. For what it is worth, I tend to use Firebug quite extensively and it is fairly easy to replicate this issue by starting a new instance of Firefox in the morning and start using Firebug for DOM and CSS manipulation. By lunch time, Firefox is up to around 800 mb of RAM usage and the UI thread become unresponsive. I have no doubt Firebug is a contributing factor, but would be nice to have Firefox protect itself from things like that. To add to this, my colleauges also run into the problem with similar configurations (Firefox and Firebug) on a daily basis. So maybe it would be a good starting point to have Firebug installed and pretending you are a web developer when trying to replicate this bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=558861 https://bugzilla.mozilla.org/show_bug.cgi?id=565217 (linked from here as a dependency already) Brendan, myself, and other senior Mozilla folks want this problem resolved at LEAST as much as anyone else on this bug, or likely to join this bug in the future. We believe that we have a bunch of things arriving shortly in the FF4 betas that will fix it, but many of the reports in this bug are simply not detailed enough for us to say one way or the other, which is why people keep asking for more data. It's not because we don't believe that it's happening to the commenters -- why would they be lying? -- but because we want to understand the problem better, and make sure we're doing everything we can to fix it. (It's also interesting to me that people are still seeing Flash videos stutter after Firefox 3.6.4 on Windows, because Flash now runs in a separate process and shouldn't be as affected by what is ailing Firefox.) If you can provide xperf traces of I/O activity, that would be very welcome in this bug. If you can provide a set of specific steps to produce pauses or outrageous memory behaviour on your system, that would also be very welcome. While I sympathize with the dissatisfaction people are expressing, angry rants or accusations are not welcome in this, or in any other bug. It does not help resolve the problem we all want resolved, and it's simply not respectful. We routinely ban bugzilla accounts for such abusive or inconsiderate behaviour -- it's very much similar to going into someone's office and yelling at them.

Why does it seem like the comments on this bug are running in circles? I've been following it for over a year now and thought it was pinned to garbage collection with some certainty months ago. It was also well established that this bug affects all areas of the chrome, rendered pages, and yes...forms. Anyone who takes a minute to look at this bug's dependencies will see that making the garbage collection more responsive is in the works, and has the appropriate bugs filed. They will also see that Zbigniew has been trolling this bug report for about 6 months now. It's pretty clear that this bug affects a large proportion of users, even if they are not aware of it. But the ball is rolling...and I don't think additional comments reiterating the first 150 are helpful in any way. Thanks to the developers that are working on this. It does seem odd that none of the large development team has ever experienced this bug, though, considering every Fx installation I've ever used exhibits these symptoms after a long enough period of time or significant resource usage...

These are mine extensions (I will give you my wife ones later): Aardvark 3.0 Adblock Plus 1.22 Adblock Plus: Element Hiding Helper 1.0.6 Adobe Contribute Toolbar 5.0 AVG Safe Search 9.0.0.855 Bar Tab 2.0 CGPersia Toolbar 0.1b CoolPreviews 3.1.0625 DOM Inspector 2.0.8 Download Statusbar 0.9.7.1 Firebug 1.5.4 Flagfox 4.0.9 IDM CC 6.7 (Internet Download Manager integration module) Java Console 6.0.21 Microsoft .NET Framework Assistant 1.2.1 Password Exporter 1.2.1 Skype extension 3.3.0.3971 SmartWhois Launcher 1.11 Sotink SWF Catcher 1.4 Torbutton 1.2.5 Web Developer 1.1.8 Yet Another Smooth Scrolling 3.0.14 Zend Studio Toolbar 2.3 Zotero 2.0.8 @Adam I am not "trolling" but simply - try to motivate these mysterious developers to some effort. You are perfectly right with your notice: "It does seem odd that none of the large development team has ever experienced this bug, though, considering every Fx installation I've ever used exhibits these symptoms after a long enough period of time or significant resource usage..." This exactly my feeling - this must be the result of keeping their "development boxes" in aescetic purity what definitely is not regular pattern of computer usage. IMHO - if they started using FF rather than developing it - they would observe this bug immediately!

FWIW I'm a core developer, I do see problems like this, I have tracked them down to GMail (see 497808), and we are working on it.

Happens regularly

Happens less often, usually corresponds with the spikes

I am running SysInternals Process Monitor and it shows CPU spikes in FF, but no corresponding IO spikes. Also, SysInternals Process Explorer shows periodic FF activity that seems to correspond with the spikes. I've attached two log dumps in CSV format. One shows the following two operations in succession: "TCP Send","localhost:54781 -> localhost:54782","SUCCESS","Length: 1" "TCP Retransmit","localhost:54781 -> localhost:54782","SUCCESS","Length: 0" The other has more operations. Zbigniew, I have the following add-ons from your list, as reported by Nightly Tester Tools 2.0.3: Adblock Plus 1.2.2 Adblock Plus: Element Hiding Helper 1.0.6 BarTab 2.1b1 Download Statusbar 0.9.7.1 Java Console 6.0.21 Microsoft .NET Framework Assistant 0.0.0 [DISABLED] There are many more that I use. I'll post the full list if required.

> I have tracked them down to GMail Robert, If I restart the browser without ever opening a GMail page, I still see the problems.

The following attachment will create tons of DOM element references. Start a new instance of Firefox 4 Beta 6. Navigate to the attachment. Every 10 minutes, refresh the page. Once the memory consumption of Firefox reaches around 350 MB, the UI thread starts becoming unresponsive. Initially the stalls are very small, but they start growing in length. The example is fairly self-explanatory, but the numbers being output are the amount of time it takes to generate 200 DIVs. Obviously the accuracy is dependent on Firefox's internal time resolution. Hope this attachment helps.

Sahab, this is actually very useful! I haven't seen this testcase before. Lets open a new bug with it. This might be some sort of leak which slows down the cycle collector.

Bug for Sahab's test case: https://bugzilla.mozilla.org/show_bug.cgi?id=599694

Ok, I decided to share with you my system. Here you are: Here you have Process Explorer view of fresh FF run on my system: http://img692.imageshack.us/img692/6483/ff00.jpg Here it is how FF looks after several hours of continous usage: http://img409.imageshack.us/img409/894/ff01.jpg http://img718.imageshack.us/img718/8631/ff02.jpg Here you see the process tree: http://img715.imageshack.us/img715/5327/ff03.jpg And here are details: http://img843.imageshack.us/img843/4706/ff04.jpg http://img139.imageshack.us/img139/2285/ff05.jpg http://img269.imageshack.us/img269/8678/ff06.jpg And finally here: http://rapidshare.com/files/423947074/firefox.exe.txt You have the Process Explorer FF dump. I hope this might be helpful.

#170 is extremely useful. Thanks! That clearly looks like a leak.

Do you have any extensions installed?

I have laredy listed here: https://bugzilla.mozilla.org/show_bug.cgi?id=490122#c161

Perhaps I should point this clearly: Firefox hangs also if I disable all add-ons! As for me - sure - that was one of my first tests with this problem: I disabled all extensions but still had this nasty issue !

Alright, after my last message with my take on FF4, I decided to see what would happen if I used a new profile. Using a new profile on FF3 wasn't much of a succes for me as I missed my XMarks. But since I needed to switch from XMarks to the FF4-integrated Sync anyway, I decided to set up a new profile and only use Sync and add DOM inspector and a few search engines. What I noticed first is that it was notably more difficult to get FF4 to reach 600+ MB memory usage with a new profile. At this moment I've been running this instance of FF4 for about 4 or 5 days and the memory usage is 560 MB. From what I remember this is much less memory usage compared to FF3 and FF4 with my old profile. If I remember correctly the memory usage for FF4 with old profile hit the 1 GB last time I used that profile. The experiences from my previous report (comment #143) still stand. What I would like to add is that I now experience the stuttering of sound at the very same moment as the pausing of my cursor in form fields. These pauses appear with (i'd estimate) minutes in between. They consist of one (most of the time) to three (about one in ten times) A-B loops, and sound then continues. These pauses also occur when I see a CPU% peak in the performance graph. @Robert O'Callahan: Thanks for posting. I usually have a gmail or google for domains window open but others report they don't. @Shawn: I'm looking forward to FF4b7 to see if the changes to garbage collection work for me :) Is there any date when b7 will probably come out? Concerning the exact scope of this bug: the word "forms" really is in the first report. After that some people mention "input fields", "messageboxes" and "text input". So those symptoms really where mentioned from the very start.

After cleaning my digital house I now went from 300+ tabs to 30 tabs. Even though the number of _loaded_ tabs are about the same (most of the 300+ tabs were unloaded thanks to the BarTab add-on), the freezing problem is _much_ less apparent now. I've now had Firefox 3.6.12 running for two days and still just reached 420 MB RAM. With 300+ tabs it took me just two hours to reach that, and it also feels like there is now considerably less freezing & CPU consumption than before for a certain RAM usage. The FF process even reaches 0% CPU quite often in Windows Task Manager, something that never happened before. The behaviour CAN be reached also with only a couple of tabs etc, but even if it's an interesting fact it's not at all as quick or apparent. Conclusions: - When trying to provoke and find this bug, open LOTS of tabs. Several hundreds. They don't even have to be loaded, you can use BarTab to prevent all of them loading and taking time every time FF starts. It seems to me that there is some clumsy code running through all the tabs every time FF needs to do a memory allocation or similar action. Developers, please use lots and lots of tabs and try to nail out where the execution is kept for so overly long times. - When trying to avoid this bug, keep your tab count decently low.

i have had past experiences with the following extensions and applications causing issues with firefox memory management and garbage collector Extensions Cooliris/PicLens NoSquint. Skype Extension (Leaks, crashes, freeze on exit, weird page issues) HTML5 extension for windows media player plugin. (Microsoft) Applications Avast (Webscanner module breaks garbage collector) AVG 9 (various reports of memory leaks in firefox with this) Kaspersky IS (mozilla virtual keyboard 3 module breaks garbage collector - This was confirmed by myself a long while back but i no longer have a kis license to verify if it is still a problem. In the case of this artifact however; I don't think it is directly related to memory usage in this case, my typical session uses 800MB at start and i don't get the stalls right off the bat, they start to occur after a few hours of usage.

I upgraded to Firefox 3.6.16 and saw the announcement of Firefox 4: http://www.mozilla.com/en-US/firefox/3.6.16/whatsnew/ One of the mentioned new features is that it is said to be "AWESOMELY FAST". I take it as this bug is finally fixed???

No, mr@analogue, it isn't. Had pauses of over 1 second yesterday - unfortunately detaching the profiler killed Firefox before I managed to get a good trace.

iirc, the important GC/CC changes to fix this will not land till Fx4.x or 5.

As one of the original reporters on this bug, here's my experience on the progress so far. I've been running the Firefox 4 beta's since September 2010 (beta 6) and posted my first experiences in comment #143 saying that the pauses where already less noticable in Fx4b6. Somewhere in November 2011 I even switched to using the Minefield dailies to see the progress faster (instead of waiting for beta's) and what I can say is this: The pauses where considerably less noticable in the beta's and they must've disappeared after I started using the dailies. On 3.6.x, I was very, *very*, much frustrated by these pauses, for weeks and weeks of using Fx. When they started occuring I noticed them in every video, every webpage, every formfield. Now, I have not experienced this frustration for months, if not half a year. I completely forgot about this problem existing until I got an update e-mail for this report. I can recommend every single one of you to start with a new profile after installing Fx4 though. I even uninstalled my 3.6, 4 beta and Minefield and removed all settings (it's an option on uninstalling) before installing Fx 4 to make sure it was completely clean. I'm still doing long browsing sessions with the same browsing behaviour. Memory also seems much better managed. With 3.6, I never noticed Fx giving memory back to the system but that does happen in 4.

A new profile won't do jack because most users will just install the same extensions again (and my profile is manually kept clean of old junk extension data anyway). Other external factors also apply such as poorly written DLL's and microsofts own plugins (lol, it astounds me how bad microsofts extensions are) Not to mention Firefox 4 has several new issues with GC causing memory to balloon in certain scenario's. page loading eats up to 2x as much memory and once loaded Fx4 uses 1.5x as much memory (1GB in Fx4 instead of 700MB in Fx3) The problem always comes back to the Session data and long session memory GC/CC tracing performance getting less and less as Fx4's "Actual" memory use increases (Allocated is not the same as In use.), concurrent GC is still nowhere near landing.

Also, through my testing there are several extensions which directly affect the smoothness of firefox by increasing the length of each collection cycle, These are the min and max with these extensions running not the amount of delay added Adblock Plus 30-31ms Google Toolbar 27-29ms OptimizeGoogle 17-24ms (This extension is only a problem within the first few minutes of opening firefox, it eventually settles in to the minimum and stays there) Ablock plus and google toolbar runnin together can easily put the delay over 33ms and you will feel the stutter because of it. the amount added for most extensions is minimal (not even 3ms in most cases) but the worst offenders are Ebay sidebar - increases the length by 7ms Google Toolbar - increases the length by 10-12ms Adblock Plus - Increases the length by 10-15ms Session Manager - Increases the length by 6-10ms normal delay is 13-18ms with an average of 15 with no extensions or plugins running. so you can see why a combination of 2 or 3 of these extensions adding 10 each would be bad.

I do use AdBlock Plus, just to block the odd irritating SWF, and to extract FLV URLs. On my work PC, I've just disabled it via its tray icon to see whether that helps (there aren't even any rules defined). (This is 3.6.16 in XP; I can't go 4 until I have the time to completely reconstruct my profile from scratch as using my Fx 3 profile in 4 ends up with Fx 4 being utterly hosed.) For me the most easily observable offender is Firebug -- start debugging a site, and Firefox 3 can start freezing painfully in seconds (so bad that you feel that you can't continue like that). The severity of the onset seems random but typically only a mild lag during each GC cycle, and the performance decay with Firebug open is also variable. But it's certainly a very obvious trigger of the problem.

"(This is 3.6.16 in XP; I can't go 4 until I have the time to completely reconstruct my profile from scratch as using my Fx 3 profile in 4 ends up with Fx 4 being utterly hosed.)" List your extensions, i'll tell you which need to be disabled during the upgrade. particularly, any free-toolbar type toolbars have to be disabled else the layout screws up, and there are some issues with migrating a profile with a Persona enabled.

(In reply to comment #182) > I can recommend every single one of you to start with a new profile after > installing Fx4 though. I even uninstalled my 3.6, 4 beta and Minefield and > removed all settings (it's an option on uninstalling) before installing Fx 4 to > make sure it was completely clean. Although being a "good" advice, I'd consider this to be very dangerous for the solution of this and other bugs. The new version must handle upgrading from an older version with lots of baggage. If the big profile data chunks have become problematic over the years, they need to be handled - not avoided - for the millions of typical users. Don't allow Firefox to go the Microsoft way of uncontrolledly big installations that rotten and need to be reinstalled regularly to run properly. > I'm still doing long browsing sessions with the same browsing behaviour. Memory > also seems much better managed. With 3.6, I never noticed Fx giving memory back > to the system but that does happen in 4. I'd like to correct that a bit. I now "upgraded" to Firefox 4 and did a quick test before and after, and what I observed (except for the extremely blurry text - what on earth have they done to the fonts??? - and the single-button menu that is stated to be more convenient than showing the menus - who outside the Microsoft office believes that?) is the following: When I go to ebay.com and open 50 ebay item pages in 50 new tabs, Firefox 3.6.16 takes 200 MB and keeps 100 MB of them after closing the tabs. Firefox 4.0 takes 600 MB(!) and keeps 50 MB of them after closing the tabs. This test is quite easily reproduced and was done in the quite clean "Guest" account on my Win7 PC, on a quite clean Firefox profile with Java as the only extension. I haven't yet had time to use it normally for enough time to get a feeling of how it behaves in a normal situation, but the graphics behaviour (regarding animated GIFs, dropdown menu drawing, and youtube videos) in Firefox 4.0 with lots of tabs open looks terribly awful! Speaking of memory consumption and not giving back the memory to the system - what bug reports cover this? Since Firefox always eats memory (even version 4!), and since the effect of this bug heavily depends on the amount of memory kept by the Firefox process (Process memory under 400 MB - never a problem; Process memory over 800 MB - always problem), I find it very strange that nothing is mentioned in terms of such dependencies.

Bugs Bug 645678 - GC Delay is increased by certain extensions right from launch Bug 644457 - Memory leak: closing tabs does not deallocate memory. Bug 637782 - Memory not being released after visiting image heavy sites Bug 643651 - Huge memory usage by WebGL leads to crash Improvement tracking Bug 640457 - (mslim-fx5) [meta] memory size reductions for Firefox 5

Guys, this is a bug report - not a support forum. Please do not spam.

> Guys, this is a bug report - not a support forum. Please do not spam. says the guy who has only contributed with comment #122 : > To all victims of this bug: I worked around this issue by using the BarTab > extension. > https://addons.mozilla.org/en-US/firefox/addon/67651/ > This allows me to keep my excessive number of tabs "open" for reference, but > they load on demand. > > Is there some equivalent of Chrome's Task Manager for Firefox, that would allow > me to blame particular page/tab for excessive resource consumption? I'm glad you noticed after a year. :-) Show us our support questions or thank us for helping...

> List your extensions, i'll tell you which need to be disabled during the > upgrade. To give you an idea, when I tried an upgrade from 3.6 to 4.0RC1, I got the weird double title bar bug again, and the address bar stopped updating as I changed tab or followed links. My saved session was discarded, so I lost every record of what I was doing -- that was pretty diabolical. It was pretty much impossible to make any sense out of the program, and I was finding that page scrolling could be a lot slower than 3 even if rendering time was hugely improved. (Naturally I backed up my profile prior to the upgrade ;) I don't seriously expect anyone to know where amongst the following list of add-ons the problems lie, but I take your very valid point to hand that re-enabling them one by one might help show which do and which do not work. A few of them already either don't work, or go unused: Adblock Plus 1.3.3 Add-on Compatibility Reporter 0.8.1 Bonus Toolbar Buttons 1.0 (mine) Controle de Scripts 1.0.3 Copy Link Text 1.5.0 Download Statusbar 0.9.8 DownThemAll! *nightly* 2.1alpha.20110319.2620 Favicon Picker 3 0.5 Flashblock 1.5.14.2 Intelligent Middle Clickums 0.0.1 (forced compatibility, not sure it ever worked) JSView 2.0.5 keyconfig 20080929 (I forget what I use this for in Firefox, but it's critical in Thunderbird due to Outlook vs Thunderbird shortcut conflicts, e.g. ^Q marks a message as read in Outlook, and quits Thunderbird ... exceptionally nasty. However, I can resolve this in AutoHotkey now if I had to) Menu Editor 1.2.7 Microsoft .NET Framework Assistant 0.0.0 (WTF go away already) NoScript 2.0.9.9 Options Menu 1.8 (forced compatibility) Paste and Go 3 1.0.4 (forced compatibility) Stylish 1.1.1 Tab Mix Plus 0.3.8.5 Toolbar Buttons 1.0 UploadProgress 0.5 (doesn't work anyway) No personas -- I have yet to find one that blends in with the UI smoothly and doesn't render the menu and toolbars completely unreadable. Presently I have 39 tabs open, so it will be some time before I'm ready to touch this, especially under the assumption that the session restore is hosed. (I turn my PC off at night, but I do hibernate it, so Firefox is only closed when the 10-second-interval freezing becomes unbearable.)

Hi again. For what its worth when I have the plugin-container enabled, all my video stutters stop. If I disable it, they come back. When stutters occur cpu is 'not'saturated which is a strange one so there is excess processor power there but it doesnt get used, so something internal on FF itself is bottlennecking. What I wouldnt mind trying is a version of FF that has no GC, just completely disabled. I had to do some tweaking in the about:config as the plugin-container was breaking java applets, I managed to get it working now tho so flash is contained and java is in the FF process. I am still using F 3.6, plan to test 4.0 on my laptop first but I am dissapointed with the UI changes I have read about, especially the menu bar and font issue but thats a seperate topic, but is the reason I am still on 3.6.16. For me the priority is having the GC stutter issue fixed, even if it means extra ram usage, although the 2 issues seem interwined with each other I think GC's ultimate aim is to keep ram usage down? so perhaps a high ram version of FF that has no GC is desired.

I went to FF 4.0 and experience less stuttering (expecially the increased stutter at high RAM usage) but there is still a lot of it if one knows where to look. The most pronounced stutter comes periodically every 6 seconds - and I clearly see spikes in the Windows Task Manager CPU Usage History (high update speed) when it happens. What is happening every 6 seconds? Then I suddenly realized that the Task Manager itself is also halting its graphics during these periodical stutters! What on earth could that be? Would that really be expected from a FF CPU performance problem?

That sounds more likely to be a GPU issue, actually...

additional feedback, I tried that page that shows GC delay, mine was 80ms every 2 to 3 turns of the dial. Shame there is no tool to see what exactly is causing the delay. I have only 12 addons and ony 2 of them I consider as major ones.

I highly recommend you set "javascript.options.mem.log" in about:config and get the CC/GC delay numbers from the Error Console instead of the dial. I found that dial to have a curious effect on GC delay - namely, drastically reducing it! Bug 646941 has the details.

thanks but I guess its a 4.x only setting? as nothing relevant is showing in the error console. Or do I need to restart the browser for it to take affect?

> thanks but I guess its a 4.x only setting? Yes, it's a 4.x only setting. It does not need a restart.

Hi, I've been looking at this thread over the past weeks and it didn't receive any new posts by a developer, so I wanted to ask whether this problem has been solved and if so, in which version? If this problem didn't get solved yet my question would be if there is any progress or if any more help is needed. I'm not a programmer myself, but I've looked into the symptoms and even made some screenshots of processexplorer to document what's happening on my machine. Some of the problems I had seem to have been caused by Adblock Plus 1.3.5 and earlier, but since 1.3.6 this got significantly better (at least these are my preliminary findings). Now session store is the bigger cause for these freezes, especially with many open tabs and a long firefox session. From what I have experienced there are two causes of freezes. The first one is the already mentioned session store procedure which takes place every ten seconds. To my surprise session store is even able to make the taskmanager graphs lag. Something I didn't expect because taskmanager is running on "high" priority whereas firefox always runs on "normal". The second cause of the freezes seems to have been sigificantly catalysed by adblock. What I saw was that after only a few hours of heavy browsing (many open tabs to start with, then open and close many new ones) I got freezes that were more often then the 10s interval of session store. This interval got smaller and smaller until eventually it reached 2s where I had to restart firefox because it got unbearable. These intervals showed up in process explorer as peaks in cpu consumtion. So every 2s there was a spike. Similarly there was a spike in memory consumption. Every 2s it spiked. These spikes in memory consumtion are interesting because when firefox starts they are almost unnoticable. Screenshots: After some usage: http://img834.imageshack.us/img834/3580/3ff4idlewithoutadblock.png Escalating: http://img685.imageshack.us/img685/7700/7ff4idlewithoutadblock.png Worst case: http://img140.imageshack.us/img140/9757/12ff4idlewithoutadblock.png From what I found out FF3.6 and FF4.0 react the same. Even without Adblock this behaviour will occur, only it will take more time (I think it took me three days on one occasion). I have checked this with addons disabled. There is one big difference though. I ran some tests with the garbage collector demo and FF4 reacted significantly worse, at least that's what I think. On a fresh FF4 this happens when the GC Demo is run: http://img8.imageshack.us/img8/2650/2ff4garbagecollectordem.png Later: http://img233.imageshack.us/img233/4053/8ff4idlewithoutadblockg.png And then: http://img5.imageshack.us/img5/1566/temp15garbagecollectord.png In the two latter screenshots FF4 starts to alocate a whole GB for the gc demo! On both occasions I aborted the demo because I didn't want to kill my system. In the last screenshot it's apparent that 1GB was alocated a lot faster! From my experience, FF 3.6.16 doesn't react that way. Even after some usage (the spikes are already there) and adblock enabled the gc demo doesn't get out of hand: http://img823.imageshack.us/img823/6303/2temp28ff36withadblcokg.png So this were my findings. The only thing I didn't post the screenshots of are those made of the "Threads"-tab in process explorer. I tried to take some at the moment the freezes occured, but I don't know whether they could be of value so I didn't bother. Let me know if you need them, too. Maybe one of the developers can make sense of this. Cheers, Porter

I've looked through several bugs, and this one appears to be the closest to my situation, although I'm using Firefox 4. It also primarily happens when loading pages. Is this the defect I should use, or should I find or create another?

This incredibly annoying behaviour is still present in FF 4, 5 and 6 -- and it makes me SICK. As soon as FF does just about anything like loading a tab (e.g. in the background), scrolling gets jerky, even the mouse pointer jerks at times. Opera on my 10years old 1GHz netbook feels and behaves MUCH MUCH more crisp than the latest FF varieties on a quad core super duper SSD multi graphics card PC system. I can't simply believe that this is still not fixed (not even bing worked on) after like half a decade.

Guys, I got a fix for the problem: Go to configuration, under software click on uninstall a program, look for Mozilla Firfox, double-click it and follow the instructions. Then surf to google.com/chrome and click "Download Google Chrome". Then launch the install. Now use Chrome to watch Youtube clips: It plays as smooth as Tennessee whiskey. ;-)

@202 Troll elsewhere.

Interestingly, I seem to have found a possible culprit (at least in my case). I just enabled all of my ~30 extensions one by one, and sure enough the one that made scrolling through a Google Images search result list (yes, the yucky new "Bing" design variety) practically impossible and incredibly jerky was NEITHER Adblock NOR CoolPreviews but the "Conform Search Box" extension, of all things. I tested it a couple of times and every time I'd disable "Conform Search Box", I would not get any jerkyness when scrolling (and vice versa). I have however not yet tested what happens after using FF6 for a while. Anyway, I'd suggest that what FF urgently needs is a tool that can tell WHICH of one's extensions leads to problems with (especially) GUI performance.

Sorry. It wasn't DIRECTLY the "Conform Search Box" extension's fault. Instead, with "Conform Search Box" enabled, SearchWP in turn was trying to highlight the search terms on that Google Images results page. The latter (highlighting), not the former (search term synchronization) was what made scrolling (extremely) jerky.

(In reply to comment #205) > Sorry. It wasn't DIRECTLY the "Conform Search Box" extension's fault. Hi David Sounds like you're describing two other problems. In comment #201 you were probably referring to Firefox's threading model, or painful lack thereof. In comment #205 you were referring to continuously slow performance for a given task. This bug relates to a fault where around every ten seconds, Firefox hangs for a second or two, regardless of whether you're interacting with it or not. The length of these hangs increases until Firefox is finally restarted, but the period is fixed (the garbage collection cycle period). Having upgraded my home PC from Firefox 3.6 to 4.0, I find that it will run for much, much longer before the every-10-second freezes start to become noticeable. This may be due to improvements in 4.0, and it may be due to alterations in my add-ons corresponding to the update, or possibly both. However, Firefox 4 still doesn't "get" threading, but that's for another bug somewhere.

the application is already multithreaded in that several individual threads operate off a single parent thread. the trouble is the single parent thread has to provide for all plugins, content and network processing that the browser presents to the user. IPC Content will break the parent thread down further to allow it to issue jobs across multiple cores using a multiprocess design. multiprocess interaction is not the only possible way to scale the browser across multiple cores, however its allot better in terms of content isolation, where content could crash the browser without taking out the entire browser session, it could likely just require to reload the affected pages. Certain extensions on firefox 3.x can increase the rate at which the pauses occurs by defaulting to a high trace latency right from start.

I'm not so sure if this has to do with garbage collection or threading AT ALL. My experience is that FF has become absolutely unusable on machines with slower graphics. This is not even so much related to scrolling or periodic hanging of Firefox alone but due to the fact that FF grinds the entire PC down to a state of unbearable jerkiness -- i.e. the mouse pointer hangs and jumps even if FF is not even the active window. This happens on several of my PC's, one of them being a very powerful XP machine that however has one additional graphics card that is rather slow, for displaying 2D office type, or static content on a third monitor. As soon as FF is moved to (or started freshly on) that third monitor, my entire system becomes practically unusable because the mouse hangs and gets incedibly jerky as long as FF is busy for example drawing or reloading a page. Every other browser has no problem whatsoever working on that third monitor (or on my old netbook respectively -- where FF also is the only browser that is absolutely impossible to use). Therefore I'd say that FF obviously and already has a general (major) problem simply with drawing its contents on the screen (on less-than-high-end computers) without grinding down the entire system. Sorry guys but there obviously is something SERIOUSLY wrong that is probably simply Gecko (and not Javascript-, multi-threading- or GC-) related.

create a new bug, your issue is unrelated to this one.

Honestly, I would SO MUCH LIKE to quit Firefox. The only thing that forces me to stick with FF are some add-ons that are not yet available to other browsers. Yes I certainly would like to leave a somewhat more constructive feedback. However, I have done so for at least five years (about the continuous FF performance problems) -- and nothing has changed, seemingly it's not even being worked on (see here). This is all very disappointing. Instead of rolling out supposedly "major" new FF versions every couple of months (that basically only break one's add-ons compatibility), bugs like this should finally be fixed, after all. I suppose pimping and Google-Chrome-Mimicking the UI all day long is just SO much more fun and trendy for many developers nowadays than actually crawling under that (oily) hood and fixing the stuttering FF engine. Sorry but this is just how I feel about Firefox at present -- which still is one of my most important working tools but has long stopped to make me happy as a user.

Actually I can only fully agree with David.P - fixing persistent bugs should be a top-priority for developers not a nasty burden. I am also often confused with all these new, not so seldom pointless features and changes introduced with every FF releases and I am equally disappointed seeing old problems untouched. It is a course of modern days media - unless you provide whatever "brand new ****" you immediately become "outdated ****". This is all ill odd and it's a real shame serious open-source software developers get affected with this disease.

This will be probably fixed when full Electrolysis (e10s) will land. But devs working on it, so no worry.

We do test on netbooks and hardware like that. Unfortunately "Firefox is slow and jerky on this old PC I have" is a very difficult sort of bug report to work with, there's just not enough information for us to figure out what the problem is. If you have trouble with a particular screen, you might want to check whether graphics acceleration is enabled, and if it is, try disabling it. Maybe there are flaky graphics drivers/hardware involved.

an unstable hardware configuration is not out of the question either.

I appreciate the comments and responses. However (and only in order to be precise) this is definitely not a user configuration problem. I do experience a) the periodic GUI jerkiness (present bug) and b) the general bad scrolling/mouse pointer performance (possibly other bug) on every PC and notebook in the house. The only thing that all those about 6 systems have in common is Windows XP AND that none of them is younger than about five years (yet runs everything very well -- except Firefox). Therefore, the developers please not only should test FF on (the latest and greatest) netbooks but generally also on hardware that is up to 10 years old (which can be perfectly normal for the average Joe out there). I'm not saying FF should be TARGETED to such old hardware. All I'm saying is that you will be surprised how much easier it is to spot the broken bits and pieces of FF's code IF you do your testing on weak hardware. BTW, while I'm typing this on my Super Duper CAD Monster PC with OS (and FF) installed in a SDRAM (!) SSD hard drive, sure enough FF will stall every couple of seconds and only spit out the last couple of letters together -- after the typical "Second's Silence for The Gecko™" discussed in this bug's thread :-(

(In reply to comment #213) > We do test on netbooks and hardware like that. Unfortunately "Firefox is > slow and jerky on this old PC I have" is a very difficult sort of bug report > to work with, there's just not enough information for us to figure out what > the problem is. Robert, this particular bug (not the graphics one) has been open for over two years, with over 200 comments, some providing lots of details. Yet, yours is the first post from "Mozilla Corporation" and it does not even mention the original problem. Meanwhile, this bug that makes FF UNUSABLE for streaming video is still not being worked on (not even assigned to a developer!) and has no milestone for resolution? Do you now understand why more and more people lose faith in FF (and in Mozilla in general) and start using *and advocating* alternatives like Opera, Chrome and even (gasp) IE? Unless you stop sweeping the real issues under the rug, as soon as my favorite extensions are supported under Chrome, I will jump ship. > If you have trouble with a particular screen, you might want to check > whether graphics acceleration is enabled, and if it is, try disabling it. > Maybe there are flaky graphics drivers/hardware involved. I believe that if any other application would exhibit the behaviour David P. is alluding to, he would mention it. I fail to imagine any "flaky graphics drivers/hardware" having an anti-FF bias and manifesting bugs only with it. Honestly, this is what I came to expect from Mozilla: blame the add-ons, blame the extensions, blame the drivers, blame the hardware, blame the OS, blame the user, blame the gremlins... How about searching for the REAL cause of these bugs (and finally fixing them) instead of for more excuses to ignore them?

"I fail to imagine any "flaky graphics drivers/hardware" having an anti-FF bias and manifesting bugs only with it." AMD, Nvidia and Intel are experiencing issues with their windows XP drivers hitting the non paged pool limit when doing accelerated browsing + accelerated flash. This can result in either 2 scenario's 1. Performance goes to hell as the kernel and particularly graphics driver cannot dynamically increase the required non page pool further to process commands and the likes. 2. Instant Crash.... actually this is the common result of running Starcraft 2 or The Witcher 2 on windows xp lately. the /3GB switch is useless in this regards as the pools use an autodetected maximum (usually around 200MB for each) value at start which tends to be far less than the possible maximum (roughly 380 paged and 300ish non paged).

Anyway, this bug has been replaced by another tracking meta-bug for the Cycle/Garbage collectors iirc and Moz would prefer the users to continue the discussion on the forums. Extensions ARE a part cause, Plugins ARE a part cause, Excessive Memory use is a cause (and excessive memory use can be brought on by the first 2) All contribute in part to increasing the delays in the memory trace that runs during cycle and garbage collection. The bug has not been discarded at all and work is ongoing for the Generational cycle collector and concurrent collectors which iirc 1 does partial traces and the other is designed to perform the trace without disrupting the other parts of the browser (such as plugin content). Firefox 4.0/4.0.1 are not great examples of the optimisations done to the collectors as going by posts at mozillazine PGO was disabled for these releases, whilst 5.0 and on will have it enabled. The status of this bug depends on another bug which is actually blocking another, so its not like things aren't happening, everything is going towards preparation for future changes to the way the browser operates behind the scenes.

This is Firefox 6 after 10 minutes of browsing on Amazon, now sitting there doing nothing, other than making 100% CPU core spikes every 7 seconds (of course blocking user input/GUI response every time) and pathetically using 0,8GB for three tabs. http://666kb.com/i/bucq4uk4yo681a50j.png FF is UNUSABLE, UNUASABLE, UNUSABLE! Please, please fix this.

if firefox is using 800MB on just 3 tabs, your profile is broken. you know Aurora is unstable code yes... seriously!.

Just to be sure — these spikes, I presume they're caused by the GC walking the heap looking for stale objects? On several occasions, just opening Firebug is enough to severely exacerbate the problem, so that's not going to be the result of memory leakage and/or accretion of stale data. (I should probably file a bug that Recently Closed Windows fails to obey the limit, and grows forever, but that might be Tab Mix Plus's fault.) As I understand it, the fix is going to be to make the GC pre-emptible so that, regardless of the heap size, it will only walk it when you're not looking. So the CPU spikes will remain there, but only when you're not touching Firefox. I presume that Flash video playback (a hands-off activity) is unaffected because, since FF 4, it now draws into a window overlaying the Firefox window, and shouldn't be upset by Firefox not listening. In terms of overall performance, esp wrt David.P, I'm using Firefox 4 on an old Dell OptiPlex GX270 SFF (6–7 years old), P4 2.8 (HT), 2 GB, PATA, Intel GMA onboard video, XP SP3 32-bit, no anti-virus, and the performance doesn't seem as good as 3, but it's pretty usable. One site I visit chokes in FF 4 due to the level of stupid animated GIFs, but otherwise, I'm happy. The "freeze disease" (GC walk time increase) dropped dramatically with 4 – I've gone from being able to grind it down in hours, to only starting to see it after a few weeks (bearing in mind PC is normally hibernated). I don't know whether this was due to the upgrade to 4, or the revision of my add-on selection. I certainly urge David.P to try a clean profile and try pruning the add-ons list. I agree that 800 MB from three tabs seems excessive – Firefox 4 at home is on 600 MB after a few weeks. For comparison, my work PC runs FF 3.6.17, on a Dell OptiPlex 330, Core 2 Duo E4500 2.2 GHz, 2 GB, SATA, XP SP2 32-bit, ATI Radeon HD 2400 XT (PCIe). I tried FF 4 at work, but I rely so much on opening tabs with middle-click in popup windows (creates a tab bar within the popup window), and you guys ripped that out on purpose in 4, so I'm chained to 3 forever.

Work PC -> SP3. Silly typo :) Sorry.

(In reply to comment #221) > Just to be sure — these spikes, I presume they're caused by the GC walking > the heap looking for stale objects? Very likely. To tell for sure, enable "javascript.options.mem.log" in about:config and observe GC durations in the Error Console. See if the spikes correspond with GC times being logged there. Then, please attempt the steps described at the end of bug 646941. Namely: * open http://hacks.mozilla.org/2010/01/javascript-speedups-in-firefox-3-6/ * run the GC demo * see if the GC times drop fivefold or more. If you do see major GC speedups after running the animation, please post your results to bug 646941. > I presume that Flash video playback (a hands-off activity) is unaffected > because, since FF 4, it now draws into a window overlaying the Firefox > window, and shouldn't be upset by Firefox not listening. Plugins are out-of-process now, but long GCs still freeze flash video. I don't know why, but that's the way it is. Hence, as far as I can tell, interruptible GC will do nothing at all to help video hiccups.

(In reply to comment #216) > > If you have trouble with a particular screen, you might want to check > > whether graphics acceleration is enabled, and if it is, try disabling it. > > Maybe there are flaky graphics drivers/hardware involved. > > I believe that if any other application would exhibit the behaviour David P. > is alluding to, he would mention it. I fail to imagine any "flaky graphics > drivers/hardware" having an anti-FF bias and manifesting bugs only with it. FF4 uses graphics acceleration features that most apps don't use, so it's entirely possible. > Honestly, this is what I came to expect from Mozilla: blame the add-ons, > blame the extensions, blame the drivers, blame the hardware, blame the OS, > blame the user, blame the gremlins... How about searching for the REAL > cause of these bugs (and finally fixing them) instead of for more excuses to > ignore them? Most users don't experience problems like this, or at least not this severe, so searching for the real cause means figuring out what is different about your setup.

I'm back to FF 5 now, but it's just the same (btw. also with FF4). Obviously having a multi-core multi-GHz multi-GB multi-harddrive SSD Monster PC is not enough juice for Firefox to simply display a stupid animated GIF and not choking on it. http://m.bestofmedia.com/sfp/design/usr/de/avatars/eb/b8/7962.gif Btw. I hope the developers are aware that (an estimated) several atomic plants only have to run in order to generate the power that 500 Million copies of Firefox gobble up for ridiculous tasks like scrolling a web page or typing stupid text into text boxes (100% CPU load for holding down a key and producing "fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff") Sorry about that, but so much for "efficiency". Think about it. Please.

> Most users don't experience problems like this, or at least not this severe, so searching for the real cause means figuring out what is different about your setup. Coming back on-topic, quite a number of users experience the stuttering problem, which can makes the machine unusable for watching videos in any application when FF is running. I would call that a significant problem and yet Mozilla seems to ignore it. How comes?

primarily because users such as yourself fail to engage in intelligent conversation, fail to provide the necessary information. etc...

Perhaps the users experiencing the most problems could sent their Firefox profiles to Mozilla for study. Of course, privacy should be protected. If I recall correctly, something similar was done in the course of a Reddit campaign and also to troubleshoot some other bugs.

(In reply to comment #228) > Perhaps the users experiencing the most problems could sent their Firefox > profiles to Mozilla for study. Of course, privacy should be protected. Mine is over 130MB and contains 2855 files. Can you suggest a fool-proof way of sanitizing it of all personal or sensitive information?

(In reply to comment #227) > primarily because users such as yourself fail to engage in intelligent > conversation, fail to provide the necessary information. etc... I provided some information in posts 163-166. If there is anything other that you believe can be helpful, please let me know and I will try to provide it as well.

(In reply to comment #225) > http://m.bestofmedia.com/sfp/design/usr/de/avatars/eb/b8/7962.gif I presume this is something you believe worsened with 4? I'm on FF 3 at the moment (CPU usage ~2% to display that image), but yes, animated GIF performance and/or overall rendering performance seems to have dropped considerably in 4. However, wrong bug! Please locate or file a separate bug for this. This bug is about periodic freezes due to internal background processing including garbage collection. > (100% CPU load for holding down a key and producing "fuuuuuuuuuuuuu...") WRONG BUG!

(In reply to comment #230) > (In reply to comment #227) > > primarily because users such as yourself fail to engage in intelligent > > conversation, fail to provide the necessary information. etc... > > I provided some information in posts 163-166. If there is anything other > that you believe can be helpful, please let me know and I will try to > provide it as well. Ideally we'd have enough information for someone to reproduce locally. Steps like "install version V, create a clean profile, install addons A, B and C, browse to page P, and wait for 20 minutes". I know this is hard, and we're building stuff to make opt-in data collection easier, e.g. http://blog.mozilla.com/tglek/2011/05/13/firefox-telemetry/ but that's not ready yet, not for this kind of problem anyway. The animated GIF bug is bug 595671 (which is reproducible, and I'm looking for someone to work on it ASAP).

@Robert: As unhelpful as this sounds, I don't believe there are any repro steps known for this issue despite how common it is. There were a couple of times during the two years since I first took part in this bug when I was led to believe I have found some, or that someone else found some, but retrying them on a clean profile invariably fails to produce noticeable delays. Even if questionable steps like "wait 48 hours" or "open 50 tabs" are multiplied by a factor of 4. For this reason, I think we might need a plan B for this issue: something useful users can do *once the pauses start happening* that could lead to understanding the cause. I'll give two examples of what I'm thinking of: 1. Enabling "javascript.options.mem.log" and gathering evidence from multiple users (rather than just myself) that the pauses described in this bug really are due to unusually long GCs. Because if that's really so, then we could stop calling this bug "Firefox pauses" and start calling it "GC is unusually slow", i.e. be more specific, and know which subsystem causes this problem. 2. Using a debugger (such as a free version of Visual Studio), capture a sampling profile of Firefox when GC starts to take unusual amounts of time. Post these to some central location for volunteers to analyse. So if the developers could, perhaps, have a think about this and come up with a few "Plan B" steps, I'd certainly participate, and I believe a number of this bug's subscribers would too. Otherwise it seems we're just waiting for someone to spot some repro steps which might not even exist from a user perspective - say, if there's a race condition that causes a data structure to be subtly damaged, which causes it to accumulate junk over time, which eventually leads to slower GCs. We'd never come up with better repro steps than "open lots of tabs" for a bug like this. At this stage, we really need the "Plan B" for this one.

(In reply to comment #231) > (In reply to comment #225) > > (100% CPU load for holding down a key and producing "fuuuuuuuuuuuuu...") > > WRONG BUG! Not really. During the spikes, everything becomes unresponsive -- including the keyboard input. So if you're so lucky to hit one of them just as you press down a key, you'll experience this behaviour.

Maybe the developers (who according to this bug's status however have not been working on this bug for two years by now) should simply try and use mainstream tools like Sysinternals Process Explorer and/or Sysinternals Process Monitor. Then the developers (who however unfortunately are not working on this bug of course) could see that every time Firefox (just sitting there idle with three tabs consuming 700MB and making 100% CPU spikes that lock the GUI): http://666kb.com/i/buftoo6xf7bxvplis.png ...a DLL file called "mozcrt19.dll" is getting active: http://666kb.com/i/buftomy3c7skuo1mc.png Then, for example by looking at the strings inside this file: http://home.arcor.de/David-Peters/mozcrt19.dll.txt ...developers could start to identify what this file eventually is doing, and possibly track this bug down in no time. Well, of course, if they'd be working on it... ...instead of panicking collectively because Google Chrome (again!) has two or three other main versions out already, with even less toolbar buttons and even more 3D javascript realtime raytracing blinkenlights and transparent GUI animations :-P Cheers David.P

its the stack tracing causing the pauses the amount of memory used is not the complete cause, but the complexity of the memory stack as the session length increases which can occur due to a combination of reasons, 70%(Roughly) of the time a mismanaged collection of extensions that pollute the stack. now, reasons that this specific bug no longer recieves attention. 1. this was opened for 3.5, the 3.6 branch recieved optimisations and improvements to the js engine and other engines to reduce the impact of cycle collection on content but again, bad extensions do contribute greatly. 2. We are now, almost up to Firefox 5.0, which doesn't get the stuttering behavior, but plugins can lock up the content instead when the cycle collector goes out of control, i recall a bug being opened for that as well, which unlike this bug is not verifiably out of date.) Now, if a session is using 800MB's with only 10 tabs or less open, i'd start searching my firefox profile because i've obviously installed some junk app that has broken garbage or cycle collection, as well as checking the installed software running in the background. Review the following extensions if you have them installed. Extensions Cooliris/PicLens NoSquint. Skype Extension (Leaks, crashes, freeze on exit, weird page issues) HTML5 extension for windows media player plugin. (Microsoft) Applications Avast (Webscanner module breaks garbage collector) AVG 9 (unknown, but various reports of memory leaks in firefox with this) Kaspersky IS (mozilla virtual keyboard 3 module breaks garbage collector) If you want further help with your memory bloat problem that is unrelated to this one then take it to the forums. If you want to contribute to the development of the GC/CC engines and not get ignored for wasting everyones time posting in an ancient bug that was created for a version of Firefox long since deprecated install Firefox 5, or aurora if nightly isn't to your taste and just try reproducing the same jerkiness. Again if you get the memory bloat in that version, head to the forums because its probably your profile. Its long due to locking this down and creating a new unpolluted bug for Gecko 2.0, I would suggest that in that instance, it be made necessary to post full extension and plugin lists as well as collector stats.

David: Would you, even after five years of giving very constructive feedback, be so polite not to troll every time you cross this bug report? I'm not sure of whether or not you have very carefully read and interpreted the replies in this thread, or are unfamilair with the development processes in big software projects, but I think stuff for THIS *particular* bug has been pinned down to garbage collection and several improvements where made on that in the past. To sum it up; 1. If you can prove your bug has nothing to do with garbage collection, then open ANOTHER bug describing the same symptoms with a different cause. Start the report as you would providing all the basic details. 2. There have been VERY noticable improvements since this was reported. I'm here from comment #5, did my best to get valueable info here, and now I no longer have any troubles. Actually for me, I would consider this SOLVED because of the progress that was made. 3. Improvements ARE STILL being worked on but the progress is reported elsewhere since improved GC is part of a bigger proces. It's nonsense reporting them here since the work that is done is not so much related to solving this particular bug but related to improving performance from the ground up. That's a whole lot more than just this.

@Danial: - I have none of these extensions or applications installed - I use Firefox with a virgin profile created a couple of days ago from scratch - I am seeing this problem on Firefox 4, 5 and 6 - the screenshots are related to Firefox 5 Quite obviously, and as can be seen from this bug's discussion, this bug has NEVER been resolved (even if it should only be related to an add-on after all which also is an open question). Cheers David

OK, in order to be even MORE constructive. I have just deleted (OK, moved) my Profile folder (this is FF 5 Portable). For safety, I have also deleted every Mozilla folder under C:/Documents and Settings/etc. a) then started Firefox (of course now in absolutely virgin state). b) then INSTALLED LASTPASS! (in order to be able to log into Bugzilla) :P c) opened like 30 tabs on eBay, and some with animated GIFS etc.. Scrolled up and down a couple of times in every tab. Opened and closed 20 more tabs. And so on. Sure enough, after a couple of minutes, scrolling started to get jerky! Argh! NOW, just to be sure, I UNINSTALLED LASTPASS (remember, this was the ONLY extension installed). Repeated above steps a) through c) . Now, about 20 minutes into this session, again with like 30 eBay tabs, FF5 takes about 395MB, practically NO CPU load whatsoever, even that animated 30fps GIF runs perfectly smooth, no CPU spikes, no scrolling hiccups, nothing. http://666kb.com/i/bufwptxzme6u6g20k.png Therefore: Could it be LASTPASS after all that is the culprit?!? Which would be bummer if it is true because LastPass of course becomes absolutely indispensable once you start to use it on all your machines and in all your different browsers. Anyway, could everyone who also sees this bug try and uninstall LastPass if they use it and then check and report back if the problem goes away? Thanks already Cheers David.P

(In reply to comment #239) > Sure enough, after a couple of minutes, scrolling started to get jerky! Argh! To make sure we understand you correctly, by "jerky", do you still mean that the program pauses around every 10 seconds or so? You didn't include a screenshot of the problem, only a screen of no problem.

> To make sure we understand you correctly, by "jerky", do you still mean that the program pauses around every 10 seconds or so? Yes. But it was only a couple of minutes into the session and I though heck, could it be true it is Lastpass, which is why I didn't continue with screenshots etc. but instead rushed to uninstall LP, and started over. (Un)fortunately, I'm off into holidays tonight, so I won't be able to do much more testing for a week or so. Cheers David

> To make sure we understand you correctly, by "jerky", do you still mean that the program pauses around every 10 seconds or so? Yes. But it was only a couple of minutes into the session and I though heck, could it be true it is Lastpass, which is why I didn't continue with screenshots etc. but instead rushed to uninstall LP, and started over. (Un)fortunately, I'm off into holidays tonight, so I won't be able to do much more testing for a week or so. Cheers David

No lastpass here, but I do use Xmarks.

Did anybody actually read my post? This is it: https://bugzilla.mozilla.org/show_bug.cgi?id=490122#c199 I would like to sum up a few points that I made in this post: 1. "I have checked this with addons disabled." (Don't ask me whether I just had them deactivated or I used a new profile. What I am quite sure of is that the profile was quite new, because at that time I was testing a lot.) 2. "From what I have experienced there are two causes of freezes." a) session store (Because the interval is 10s and some workarounds suggest to increase the session store interval which supposedly works. I never checked this.) Does session store initiate a gc run? b) the other spikes that are not session store related will occur more often and will use more cpu the heavier and longer FF was being used 3. Browsing in FF 4.0 while running the garbage collector performance demo in the background will make FF start to allocate memory which it won't release. Depending on how long FF already run, this can result in the allocation of 1GB in about 60s. This can either result in FF crashing or rendering your own system unresponsive until it crashes as well. Whichever comes first. This doesn't happen with FF 3.6. 4. Just one addition to my post: my virus scanner is Avira Antivirus Premium and has been for years and I'm running Windows 7 64bit. Moreover I would like to point out that my post is just an invitation to immitate the steps I took. It's not meant as a last answer in this matter. After all I could have screwed up some of the tests. The only new thing I found out yesterday was that FF 4.0.1 started with a fresh profile (no addons) would release unused memory after 10s, but with the gc performance demo running in one tab it would take sigificantly longer. One time it took ~180s. I probably won't have to point out how this can be abused... A great way to demostrate this is to start the gc demo and browse through facebook photo albums (actually opening the photos, clicking through the stream). Then close the facebook tab with the photos (NOT the gc demo tab) and wait for the memory to be released. I'm aware that this case might be better suited for the other gc bug that has been mentioned a few posts before. I didn't test any of this with FF 5. I don't use any of the extensions or applications mentioned in this post: https://bugzilla.mozilla.org/show_bug.cgi?id=490122#c236

OK. In comment #239 it seems pretty clear that David's problem is triggered by the Lastpass extension (it may or may not be that extension's fault). Thank you for tracking that down, David! Please file that as a separate bug, with those steps to reproduce, so we can track it down. portertomato, your problem sounds completely different. Please file a bug about the garbage collector demo issue in part #3, with your specific steps to reproduce. Thanks!

OK, I just was going to make sure to add that this bug still is in no way resolved (also not by uninstalling the LastPass extension). Without LastPass installed, it only seems to take somewhat longer until the FF memory leak hits (or whatever that mozcrt19.dll 100% CPU spiking means, see comment 235), and scrolling (well, the entire FF GUI) hangs every couple of seconds). Btw., unfortunately FF in the meantime is the second to worst (of the major browsers) when it comes to scrolling performance, generally. I have two graphics cards with three monitors, where the stronger graphics card (Quadro FX 4500) powers the middle and the right monitor, and the weaker card (Quadro NVS 55/280) powers the left monitor. On the middle monitor, every browser scrolls great (well, except FF when it eventually starts to leak and hang). On the right monitor, only Chrome and Opera scroll perfectly, while FF and IE are rather jerky (IE somewhat more than FF). On the leftmost monitor, only Chrome and Opera are still usable at all. Both FF and IE are incredibly jerky -- almost like in Windows Safe Boot Mode (i.e. without graphics card drivers such that the CPU does all the rendering). NOTE: with FF up to Version ~3.6, this was all different: FF used to be the BEST scrolling browser of ALL MAJOR BROWSERS! However, starting with v4, FF has become the SECOND TO WORST (on all but the very latest and greatest super duper graphics cards, of course also on Netbooks etcetera). My guess is that something in the graphics subsystem of FF (starting with v4) is majorily broken.

(In reply to comment #246) > On the right monitor, only Chrome and Opera scroll perfectly, while FF and > IE are rather jerky (IE somewhat more than FF). On the leftmost monitor, > only Chrome and Opera are still usable at all. Both FF and IE are incredibly > jerky -- almost like in Windows Safe Boot Mode (i.e. without graphics card > drivers such that the CPU does all the rendering). This sounds very similar to Bug 633904. Some systems seem to have problems with scrolling on secondary monitors when hardware acceleration is enabled. Try filing a bug on that specific issue. In the mean time, disabling hardware acceleration might help.

Sorry but if I disable hardware acceleration, of course scrolling gets bad on EVERY monitor -- instead of only on monitor #3. Please note, this problem is NOT related to "bad performance on secondary monitors" -- rather, the FF scrolling performance generally has become terrible on weaker graphics cards, starting with FF4 -- while FF3 in this regard used to be EVEN BETTER than Chrome & Opera are today.

David, once again, this is the WRONG BUG! However, I will concede that I did a test on some decrepit throwaway hardware for you. I took the following machine: Uniwill N340S8 notebook with Broken Spacebar™ (wtf when did that happen?) Intel Pentium III 850 MHz 256 MB RAM SiS 630 video adapter, 8 MB shared RAM, no 3D acceleration Windows XP SP3 32-bit 1024×768 display, Firefox maximised This had Firefox 3.0 installed -- I tested my worst case page (long forum page full of animated GIFs), and this page as it's exceptionally long. Scrolling of both was acceptable for such a painfully slow computer, and something was even accelerating my scrolling, letting me zip around the page nicely (no idea what that was, I seldom use this laptop). The profile was copied off my desktop PC years ago and had Greasemonkey and other stuff installed. I then upgraded to Firefox 5, completely clean profile, and compared the two pages. Scrolling this page was almost impossible, and consumed 100% CPU doing so -- Firefox 5 is not really usable on this laptop. Raw unaccelerated performance has definitely decreased significantly after Firefox 3. Now let's consider a more realistic machine, my main computer at home: Dell OptiPlex GX270 small form factor Intel Pentium 4 2.8 GHz hyperthreaded 2 GB RAM Intel 82865G onboard 3D accelerated graphics, 16 MB shared memory Windows XP SP3 1600×1200 display, Firefox maximised I have Firefox 5 installed, and yes, I noticed a drop in performance with scrolling when I jumped from 3.6 to 4, but it's not that bad. Compared to Firefox 3.6 on my Core 2 Duo work PC, I don't notice a difference at all. I don't feel weighed down by Firefox 5 any more than 3. Now, nothing will be as fast as Opera, but Opera isn't flexible or friendly like Firefox – I've always found it to be hopelessly bug-ridden, confusing, rigid and stupid. The recent versions seem to finally be reliable, but they're still irritating, and Opera doesn't have Firefox's immense flexibility with its add-ons. Moan all you want about Opera's speed, but remember that it comes at the price of usability, sanity and flexibility. If you agree with what exactly Opera offers, then good for you, enjoy Opera, but otherwise, you're pretty much stuck without recourse, and that limitation is just not worth the boost in user interface speed.

@Daniel, no -- this is not the wrong bug. 1.) The present bug is about the unresponsiveness of the FF GUI -- which of course includes scrolling of the web page. 2.) I have been reporting my findings about the periodic hangs as well as general bad scrolling performance since FF4, which probably are related to each other (at least as long as NOBODY yet has found a reliable reason for the present bug). 3.) Please don't throw the baby out with the bath water. I didn't say that Opera generally is oh so fast and great, and FF generally oh so bad -- as your Comment 249 seems to imply. Rather, my point is that FF actually USED to be very good on weak hardware before v4 (even better than Opera & Chrome, at least scrolling-wise) -- and that of course includes its great extension system since this naturally was present just as well with FF3.x (and before). So your argument that "either you can have Opera's speed OR Firefox's usability, sanity and immense flexibility" is void, because FF3.x was BOTH, whereas, only starting with FF4, something has gone terribly wrong with whatever part of FF that now renders the GUI jerky and slow as discussed here. 4.) Btw. your tests exactly approve my point (slowness up to unusability on weaker systems, but only starting with FF4). 5.) I gladly used to have copies of FF on all of the ca. 6 PC's in my house. Starting with v4, the only PC that is still (just about) capable to run FF such that browsing and scrolling don't become a pain, is my above 'Super Duper SSD CAD Monster'. On every single other machine, be it my kid's several PC's, the Media Center, or the 24/7 "home server" Netbook, FF has become UNUSABLE starting with v4 -- because of its incredibly worsened scrolling performance AND because of the periodic hangs which include the mouse pointer (!) on weaker machines. For example, on my Netbook I can't even MOVE the mouse around on a page, because as soon as it touches just about any hover-activated element (a.k.a. link or JavaScript), the mouse pointer HANGS for half a second. A "rather" unpleasant development in my view, that suspiciously reminds me of the road that (inevitably?) has led to cumbersome bloatware with almost any "mature", mainstream software (which I used to hope Firefox would avoid).

Huh? Under Windows at least, Opera was always far more responsive than Firefox. I've always known that Firefox's UI is quite slow compared to other browsers, but that's just how it goes. Opera was blindingly fast, but unusable. Firefox was always sluggish, but approachable and flexible. It's an either/or choice and always has been. How many times do we have to repeat that the scrolling performance is NOT related to periodic hangs? For the last time, this is the WRONG BUG! The periodic hangs are due to periodic background processing (mostly garbage collection, but possibly also session saving) that interfere with the UI, that already is being investigated and worked on. The poor scrolling is most likely related to the move to hardware accelerated graphics and something to do with your Windows setup. I urge you to find or file a NEW BUG for this, because I can assure you that it's completely unrelated. It must be something to do with your own PCs, because if I can scroll comfortably in FF 5 on a seven-year-old XP box, Firefox's performance overall is FINE. Who knows what sort of software or drivers you're installing that could be interfering with the machine. A hanging mouse pointer typically indicates third-party software problems, something that's physically trapping and manipulating mouse events such as Tordex Wheel (I have to run that with raised priority on my home PC otherwise the mouse cursor does keep freezing, because Tordex Wheel isn't getting the CPU, but it's also locking out the mouse until it can get the CPU and process events; this isn't a problem on a more modern Core 2 Duo. In actual fact, the program that most commonly caused cursor freezes with Tordex Wheel was Firefox due to CPU spikes related to mouse activity). Otherwise, having the cursor freeze due to lack of program response is very rare, and suggests that something else is wrong such as your CPU being pegged. You need to take a long, hard look at how you set up your PCs. Disable all third-party and first-party nonessential software such as IntelliPoint and trackpad drivers. Update all your firmware and drivers. Test with a clean Firefox profile. Then see if you get the same problem across a wide range of machine types. Also, leave Process Explorer's CPU graph running in the tray and watch the CPU utilisation as it corresponds to your activity.

Well this might or might not be two different bugs, and I might or might not file another bug report. In any case, just for the record and in order to prevent a conclusion like ahh, just another user who is too dumb to care for his PC and afterwards blames FF.... Comment 249: > Uniwill N340S8 notebook > Intel Pentium III 850 MHz > 256 MB RAM > SiS 630 video adapter, 8 MB shared RAM, no 3D acceleration > Windows XP SP3 32-bit > 1024×768 display, Firefox maximised > This had Firefox 3.0 installed -- I tested my worst case page (long forum page full of animated GIFs), and this page as it's exceptionally long. Scrolling of both was acceptable for such a painfully slow computer, and something was even accelerating my scrolling, letting me zip around the page nicely (no idea what that was, I seldom use this laptop). The profile was copied off my desktop PC years ago and had Greasemonkey and other stuff installed. > I then upgraded to Firefox 5, completely clean profile, and compared the two pages. Scrolling this page was almost impossible, and consumed 100% CPU doing so -- Firefox 5 is not really usable on this laptop. The latter is exactly what I'm talking about. The PC's I mentioned that can't run FF anymore (since v.4) are more or less in this range, like Pentium III/IV Mobile or Celeron CPU's, passive graphics cards, no 3D etc. And there is of course NOTHING wrong with ALL of my PC's such that, of all things, they run everything BUT FF, as you seem to imply. These systems are all in perfect working shape, some of them even run Windows 7. So please note that it's not me misconfiguring every PC I lay my hands on -- but instead the latest changes in FF4 onwards that unfortunately lead to the exclusion of weaker systems for the usage of FF. The netbook where the mouse jerks just when moving it around over links in FF4+ admittedly is an old subnotebook, high end but from 10 years ago (Portege R100) -- but it still runs Opera or Chrome (or Firefox 3!) like mad. > The poor scrolling is most likely related to the move to hardware accelerated graphics No. It might be related to some (not so successful) CHANGES that obviously have been made to the hardware acceleration in FF. But the scrolling in FF of course always has been hardware accelerated (switch your graphics card's hardware acceleration off and you see the difference). Rather, it seems as if FF4 to 6 DON'T properly support 2D hardware acceleration anymore (on weak hardware). Thus, for me it seems as if with FF (not unlike with the graphics card industry lately) more and more valuable, down-to-earth 2D performance is sacrificed in favor of optimization for fancy 3D stuff like "real time 3D javascript raytracing in the browser" and other (rather useless) BlingBling. EoT David.P

Just to be 100% sure, if you disable hardware acceleration, Firefox is the *ONLY* program that scrolls slowly? If you install a new PC, and don't put the video drivers on, scrolling anything is painful. (I remember disabling the ATI driver on my Mac clone thinking I didn't have an ATI card, then started wondering why scrolling was so painful ... It took someone to point this out for me to realise what I'd done wrong. And yes, I had an ATI Mach64 VT onboard chip. Without hardware acceleration, scrolling sucks.) Since Mozilla claim to have only just added hardware acceleration, what makes you believe that they're lying and that it was always there but they've just gone and broken it instead? Also, Firefox 4 did NOT support hardware acceleration under XP -- I think I read that they only initially implemented it for Vista and 7 (probably because those OSes are already designed to handle it), and I imagine 5 is no different because I didn't see a speed boost anywhere.

No. If I use FF 3.5.3 on my primary monitor (i.e. the weakest of my three monitors) with the graphics card's acceleration ON, then FF3 scrolls PERFECTLY even on this monitor (actually BETTER! than the latest Opera!). If I switch the graphics card's acceleration (for this monitor) OFF, FF3's (as well as Opera's, or just any program's) scrolling gets rather jerky. This already PROVES that FF3's scrolling definitely IS hardware accelerated. OTOH if I use FF5 on this (weak) monitor with the graphics card's hardware acceleration ON, scrolling is about as bad as with FF3 and HW acceleration OFF. What's more, with FF5 there's almost no difference between graphics card HW acceleration OFF and ON, respectively, on this monitor. Both ways scrolling is VERY bad. As I said, the only thing Re: hardware acceleration that seemingly has been added to FF4++ is EITHER some Bling 3D hardware acceleration for fancy games stuff etc., OR they simply have added only a SWITCH to the settings for the user to turn OFF hardware acceleration (that always had been present anyway) from within FF -- probably because it is buggy. > Also, Firefox 4 did NOT support hardware acceleration under XP Well THAT then would explain why FF4++ is so terrible on my PC's which almost all run XP... However as I said, I DEFINITELY get hardware accelerated SCROLLING with FF3, 4 and 5 -- ALSO on XP (but of course it is much worse with FF4++ than with FF3).