Closed Bug 490122 Opened 15 years ago Closed 12 years ago

Firefox periodically becomes unresponsive/freezes: video jerks/pauses/halts; links, tabs, menus stop responding

Categories

(Firefox :: General, defect)

8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
blocking2.0 --- ?

People

(Reporter: carlos_alen, Unassigned)

References

()

Details

(4 keywords, Whiteboard: NO MORE COMMENTS PLEASE! -- please read comment 343 and file a new bug for any issues)

Attachments

(11 files, 2 obsolete files)

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.
Version: unspecified → 3.0 Branch
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.
Summary: Firefox 3.0.x periodically becomes irresponsive: video jerks/pauses; links don't work; tabs don't work: menus don't work → Firefox periodically becomes unresponsive/freezes: video jerks/pauses/halts; links, tabs, menus stop responding
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.
Version: 3.0 Branch → Trunk
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6?
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.
Keywords: hang, perf, topperf
@krylko GREAT! You seem to be able to recreate the problem. It won't be long until they have to confirm it then. Finally. :-)
Keywords: flashplayer
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.
Flags: blocking-firefox3.6?
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.
Flags: blocking-firefox3.6?
(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.
Flags: blocking-firefox3.6?
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.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Flags: wanted-firefox3.6+
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
Version: Trunk → 3.5 Branch
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.
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.
Whiteboard: READ COMMENT 39 BEFORE COMMENTING
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.
Attachment #407499 - Attachment is obsolete: true
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?
Attachment #407676 - Attachment is obsolete: true
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.
Depends on: 565217
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.
blocking2.0: ? → -
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.
Attached file Process Explorer log #1 —
Happens regularly
Attached file Process Monitor log #2 —
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.
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?
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.
Depends on: 646941
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).
When you scroll, you have to move thousands of pixels up or down a few rows on the display. Simple instructions like "please take this rectangle of pixels and put them here" require vendor support from dedicated drivers to achieve this quickly. Otherwise, Windows has to redraw every pixel one by one using a lowest common denominator approach, and as you've seen, this is pretty painful.

Applications aren't explicitly calling into DirectX or OpenGL to accelerate their scrolling, they just tell the Windows API that they want to scroll, and Windows lets the video card driver arrange this with the video card. Firefox 3 is not hardware accelerated any more than Notepad or Microsoft Word is.

What Firefox 4 offers on more recent operating systems, is the ability to directly talk to the video subsystem. 2D acceleration is all about drawing and moving single images quickly, but how do you get this image? That's why modern operating systems all use 3D acceleration to generate a 2D image -- it sounds crazy, but if you let the video card handle all the transparency and blur, the only instruction you need to issue to move a window, is to tell the video card to move a single surface. The complete process of recaculating the shadow, blur and opacity effects is left entirely to the video card.

This is why you only get Aero Basic without adequate hardware -- Microsoft never manually implemented a full-screen compositor. Mac OS X predates video card support for complex desktop compositing, so Mac OS X would draw the whole desktop itself, although it was slow. Mac OS X on my G3 iMac was fluid and smooth, but there was a subtle but constant lag on the display given the intensity of using the CPU to perform that level of 2D rendering.

Firefox also uses similar techniques now to accelerate performance, because web pages have a lot of overlapping regions, alpha transparency and the like, and I am suspecting that the result is that NON-accelerated systems like XP now experience slower scrolling, but that systems where hardware acceleration is enabled, will be able to scroll with far less CPU consumption.

Granted, you could argue that this is backwards, because faster CPUs can soak up the cycles needed to redraw a page as you scroll, but that's for you to raise a new bug on, regarding regression of scrolling speed.

Personally, I find the overall performance of older machines to be so horrid, I couldn't use them even if Firefox didn't suck. I have a spare Dell Latitude D600 at work, Pentium 4 1.4, and I upgraded it from 256 MB to 1 GB and put Windows 7 on there. Windows 7 runs OK, but the machine is just hopelessly slow even after a clean reinstall. My own laptop is a P4 2.0, 512 MB, also very slow. The machine I run that test on, the PIII 850, is excruciating. Every little thing I tried to do was like pulling teeth, and it was nowhere close to using all 256 MB :P
(In reply to comment #255)
> Personally, I find the overall performance of older machines to be so
> horrid, I couldn't use them even if Firefox didn't suck. I have a spare Dell
> Latitude D600 at work, Pentium 4 1.4, and I upgraded it from 256 MB to 1 GB
> and put Windows 7 on there. Windows 7 runs OK, but the machine is just
> hopelessly slow even after a clean reinstall. My own laptop is a P4 2.0, 512
> MB, also very slow. The machine I run that test on, the PIII 850, is
> excruciating. Every little thing I tried to do was like pulling teeth, and
> it was nowhere close to using all 256 MB :P

I have a machine at home with an AMD 3500+ CPU (P4 equivalent), 2GB of RAM and an ATI X800 card, running XP (upgraded from Win2K, no re-installs).

I run a range of tasks including C++ development, image and audio editing, etc. (not to mention browsing, email and office apps) and the performance is acceptable.  I wouldn't say "fast" but not even close to your "horrid".

I run FF3 and, right after I restart it, it runs fast enough.

Quite a lot of people use old hardware.  FF should have reasonable performance characteristics on such machines.
"P4" covers a significant performance range, from 1.3 GHz up to 3.8 GHz, including hyperthreading! Like I said, Firefox 5 is good for my 7-year-old hyperthreaded P4 2.8, no real issues.

Anywho, I've got my slow old Dell Latitude D600 machine here, Pentium Mobile 1.4 GHz, 1 GB RAM, running Windows 7 32-bit SP1. Windows 7 on this machine is not supported by Dell so I'm using XP drivers for LAN and trackpad. Video adapter is an ATI Mobility Radeon FireGL 9000; I've tried the XP drivers for it, but they're no better than the default video driver that ships with Windows 7 so I'm still using that. Just boring old Aero Basic for me.

Installed Firefox 5, clean profile, browsed to this page, because it's so enormous. Scrolling performance is faultless, both "wheel" scrolling (via trackpad) and dragging the scrollbar thumb rapidly. about:support reports that all acceleration is unavailable, blocked by the graphics driver (because the video card is far too old, hence Aero Basic).

This laptop is also around seven years old.

I think this is something where need a separate bug and a lot more test data from different machines to indicate where the performance starts to drop off.
the AMD 3500 is NOT a p4 equivalent.
also iirc the x800 does not gain hardware acceleration either as it lacks the necessary texture resolution support.
> the AMD 3500 is NOT a p4 equivalent.

No?  http://techreport.com/articles.x/7134/1

> also iirc the x800 does not gain hardware acceleration either as it lacks the necessary texture resolution support.

No Idea what you're talking about.  The X800 is a DX9 card.
(In reply to comment #259)

> No Idea what you're talking about.  The X800 is a DX9 card.

Check about:support to find out -- at the bottom, see how many windows are reported as accelerated (GPU Accelerated Windows).
> Check about:support to find out -- at the bottom, see how many windows are reported as accelerated (GPU Accelerated Windows).

Can't see anything resembling it (FF 3.6)
(In reply to comment #261)
> > Check about:support to find out -- at the bottom, see how many windows are reported as accelerated (GPU Accelerated Windows).
> 
> Can't see anything resembling it (FF 3.6)

Firefox *3*? Well then you definitely don't have hardware acceleration in Firefox.
> Firefox *3*? Well then you definitely don't have hardware acceleration in Firefox.

Of course Firefox 3 uses HW acceleration, see for example comment 254. FF 3 only doesn't have this awful, useless 3D-acceleration that makes it unusable on weaker machines, also on "green" (passively cooled) graphics cards that don't provide 3D-acceleration (but are very good at 2D-acceleration) like for example Quadro NVS or Matrox cards.

Back on topic, here's some more screenshots for whoever is (not) working on the present bug (Ben Turner being not even on the CC list):

Shot 1: This is FF 5 "playing" a video on Vimeo, stuttering and hanging every couple of seconds (as usual):
http://666kb.com/i/bv01h6ntsodpyicmh.png

Shot 2: same, but shows what "plugin-container.exe" was doing while the video was play... err, stuttered:
http://666kb.com/i/bv01ilsmsnabjdwtl.png

Shot: FF 5 after browsing for a while, again 800MB for three ****ing tabs, and the entire GUI hanging every couple of seconds.
http://666kb.com/i/bv01jaahtzk4644mh.png
 
Not Good™
3.x is NOT hardware accelerated, it uses a software implemented GDI backend,
Whatever -- but anyway, FF3 does RECEIVE 2D hardware acceleration from graphics cards. 

FF4 onwards has dropped this in favor of the 3D acceleration which only works (sort of) on 3D hardware accelerated systems. This is similar to what MS has done with Vista and Windows 7 -- with the difference that with Mozilla, users of weak hardware are out of luck completely because you can't switch that d*mned Bling Bling off AND use the old (and incredibly fast) 2D HW acceleration that FF3 profited from.

Btw it's just the same with Thunderbird 5: BAD scrolling on all but the very latest hardware (for example on my secondary monitor that is powered by a Quadro FX 4500 -- not to mention my Quadro NVS powered monitor where Firefox 4+ and Thunderbird 5 are COMPLETELY UNUSABLE.

Bad habit™, Mozilla.
the only thing hardware accelerated in GDI+ with recent versions of windows is blitting, and the introduction of GDI+ resulted in an enormous performance drop on GDI applications.

"Because of the additional text processing and resolution independence capabilities in GDI+, text rendering is performed by the CPU [2] and it is nearly an order of magnitude slower than in GDI.[3] Chris Jackson published some tests indicating that a piece of text rendering code he had written could render 99,000 glyphs per second in GDI, but the same code using GDI+ rendered 16,600 glyphs per second."

"Windows 7 includes GDI hardware acceleration for blitting operations. This improves GDI performance using new features in the Windows Display Driver Model v1.1. This allows the DWM engine to use local video memory for compositing, thereby reducing system memory footprint and increasing the performance of graphics operations. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. As of November 2009, both ATI and Nvidia have released WDDM v1.1 compatible video drivers.

GDI+ continues to rely on software rendering in Windows 7.[6]"
So what?

All I'm saying is that FF3 is great on weak graphics hardware and FF4-6 are terrible.

However, as this is the WRONG BUG for discussing HW acceleration, we should stop that discussion in order to not put everyone off the actual current topic (periodically hanging GUI).

BTW, the latter is NOT related to session storage. I'm seeing all the stuttering and hanging GUI problems that have been reported here just the same when I set session storage to something like a Million milliseconds.
Yeah.

This **** bug is just exactly the same with Firefox 7 Aurora which supposedly has its memory leak bug SO much fixed: http://tinyurl.com/FF7-Memory-Promise

Below: screenshot of the 100%CPU spikes caused by mozcrt19.dll rhythmically being accessed (see comment 235), in Firefox 7 Aurora:

http://666kb.com/i/bv127adjc51yfm8lv.png

Ahh and of course: 0,8GB for bl**dy two tabs. Yeah, this really shows how memory leaks are fixed effectively.

(not)
if you read the discussion on the fix you'd realise it only applies to discarded aspects of the heap, it won't do jack for active sites/content.

But im still surprised by the 800MB for 2 tabs.... given i can't reproduce it on any systems here.

and i hope that isn't prio you're running there.... it introduces memory leaks and prevents certain drivers from locking their desired memory range.
(In reply to comment #268)
> Ahh and of course: 0,8GB for bl**dy two tabs. Yeah, this really shows how
> memory leaks are fixed effectively.

If possible, please try in safe mode and compare the usage. Whilst there are still some leaks/quasi-leaks present (hence njn's ongoing memshrink campaign), I've never seen that level of usage just on two tabs - so would be extremely surprised if it wasn't at least partly due to extensions. Also try using a clean profile (without reinstalling any addons you use), in case something in all.js or elsewhere in the profile is exacerbating the problem.

Note: Whilst the "please try safe mode, it's got to be your extensions/try a new profile" answer is seen by some as a cop-out (and mistakenly interpreted as "we don't want to fix your problem"); it's still a necessary step in eliminating as many variables as possible. Without doing so, problems like this bug become a confused muddle - where every man and his dog chimes in with a "me too" - when it's actually more likely a mixture of half a dozen different underlying causes: some platform, some extension-based and others say due to hosed user-profiles.

Everyone who contributes here would rather bugs fixed than not, but until a bug report is clear & therefore actionable (ie: developers can replicate themselves or at least understand the problem), there sadly aren't many options remaining.
The "800MB for 2 tabs" was after browsing for half an hour, of course with opening and closing a couple of dozen tabs during the process.

Anyway and honestly, during this thread I have tried so many combinations of different versions of FF with and without virgin profiles, with and without extensions, in and out of safe mode, and everywhere it was (more or less) the same (without extensions, it only takes longer before FF gets corrupted and the GUI response breaks down).

I'm tired of it, especially since I have the impression that developers are poking around in the fog even MORE than I am myself as a user (comment 235).

Probably its even useless to post here anyway because of the "encouraging" status "Nobody; OK to take it and work on it" of this obviously DEEP and MAJOR bug.
Have you experienced these spikes on several different machines?
(In reply to comment #270)
> Note: Whilst the "please try safe mode, it's got to be your extensions/try a
> new profile" answer is seen by some as a cop-out (and mistakenly interpreted
> as "we don't want to fix your problem"); it's still a necessary step in
> eliminating as many variables as possible. Without doing so, problems like
> this bug become a confused muddle - where every man and his dog chimes in
> with a "me too" - when it's actually more likely a mixture of half a dozen
> different underlying causes: some platform, some extension-based and others
> say due to hosed user-profiles.

It would be much easier if FF contained some way to help point out misbehaving extensions.
that will hopefully be in by 8.
Honestly, I'm about to predict TODAY that FF4++ was the beginning of the end of the (once) great era of Firefox.

I have just reverted back to FF3.6 on my main (monster) PC, and what can I say: FF3.6 is blazingly fast (maybe not in "real-time 3D JavaScript games raytraycing", but who the heck needs that **** anyway). 

Scrolling is P.E.R.F.E.C.T and infernally fast on EVERY (new and old) graphics card and on every one of my monitors, there is no CPU spikes or hanging GUI whatsoever, FF3 takes about 350MB for like 20 tabs with eBay on them etc.pp. (additionally, there still is the great old Greasemonkey GUI and the great old Addon Manager which also have been terribly disimproved for the worse starting with FF4).

What's more, I have just tried FF3 vs. FF5 on another couple years old laptop (Satellite P20, 3GHz, Nvidia graphics, SSD....). While FF3 (with dozens of extensions) still runs very good on that machine (almost as crisp as Opera), especially scrolling of long pages is ABSOLUTELY fluid ----- OTOH FF5 (even in safe mode!) is simply UNUSABLE. Takes ages to start and is not even able to fluidly scroll a TEXT ONLY page without jerking. And this is supposed to be hardware acceleration! Ridiculous. (Btw, that was all on Windows 7 Professional).

Honestly I can't believe what you guys at Mozilla have been up to since Mike Beltzner has left the company. Sorry but Firefox after v3.6 simply is a box full of ****. You really have broken it all over the place.

Thus, I can only hope that my favorite extensions will soon be available for Chrome or Opera, in order to be able to leave Firefox behind, for good.

Sorry Guys, can't really put it much different than that.
geez, would someone deactivate him already, i'm tired of the "i have problems so everyone has to as well" bulldust from him.
(In reply to comment #276)
> geez, would someone deactivate him already, i'm tired of the "i have
> problems so everyone has to as well" bulldust from him.

LOL

Picard: Mr. Data?
Data: Sir?
Picard: Shut up.
Data: Yes, sir.
Picard: 15 years I've been waiting to say that.

I can see his point about really old machines, but when my creaking Pentium Mobile 1.4 (Win 7) can hugely outperform his 3 GHz Toshiba, there's clearly a missing piece of the puzzle. I also don't know where this 800 MB RAM allocation comes from -- that's not what Firefox 5 does for me, from far more tabs (albeit in XP).

Besides, the idea that Firefox 3 is immune to the periodic freezes is nonsense, and in my case FF 4 and 5 are much better in this regard (or I've just happened to remove an extension that worsens it).
OK guys when I'm saying that something "takes ages to start" this maybe is a little different from other people's perceptions. This is because as I said my main PC runs Windows and the main programs from a *SDRAM* based SSD, and therefore everything that takes longer than like 300ms tends to feel like "ages" to me. Well, I'm exaggerating, but only a little.

Starting FF5 on that giant Satellite laptop (also equipped with SSD) maybe takes 15 seconds until it's usable (reacts on user input). But the scrolling IS awful (totally in contrast to FF3 on the same machine).
(In reply to comment #278)
> OK guys when I'm saying that something "takes ages to start" this maybe is a
> little different from other people's perceptions. This is because as I said
> my main PC runs Windows and the main programs from a *SDRAM* based SSD, and
> therefore everything that takes longer than like 300ms tends to feel like
> "ages" to me. Well, I'm exaggerating, but only a little.
> 
> Starting FF5 on that giant Satellite laptop (also equipped with SSD) maybe
> takes 15 seconds until it's usable (reacts on user input). But the scrolling
> IS awful (totally in contrast to FF3 on the same machine).

Perhaps this is not a good idea, but I'd like to see a screencast of your scrolling in these different versions (both safe mode). Whenever I had problems with other things, that used to help and convince people.

[I have had the freezes in FF a lot in many versions. For me, it has gotten better somewhere between 3.0 and 3.6 and beyond, though it is still there to some degree; but mostly that is on older computers (Pentium IV). But it is quite usable compared to other programs, and it starts up nearly as fast as Chrome with no extensions. The freezing videos were more or less solved for me with the plugin container. It does hog memory, and it always has. But I have never seen those CPU spikes of yours, neither on XP nor on Windows 7.]
blocking2.0: - → ?
Firefox 5, 6, 7, 8, 9 -- all the same **** memory leak:

http://666kb.com/i/bwamkg7xm70w1hled.png (this is v.9 Nightly)

This is on a new XP install, new Z68 mainboard, new i5 CPU, ultra fast silent system with 3 SSD's and Quadro FX graphics card.

Just to remind developers that the firefox memory subsystem simply doesn't work, despite all bold announcements stating otherwise. 900MB for four tabs just sitting there during lunchbreak and getting push data from ariva.de (stock quotes).
David, is that reproducible for you? If so, that's a really great testcase that we would love to pursue. Could you file a new bug with a specific description of the steps you take in order to reproduce the problem? This will help ensure that the problem receives the attention is deserves, since this bug here is a bit of a mess.
With all this talk on HW acceleration, are folks sure this isn't GC related? It sure sounds like his memory usage is getting up there and if its forcing frequent GC collection that sure would causing GUI pausing like he is describing, right?

I'll add I seem to be seeing much higher memory usage with lastpass installed as well (it was mentioned about 200 comments back :).
It's hard to tell what's happening, but we now have tools that would help diagnose it.

Please attach the results of "about:memory?verbose" and "about:support" after browsing around for a while and seeing this problem.   If there's a memory leak or a zombie JS compartments, that will show it.  And by the way, LOTS of extensions leak to one degree or another, some really badly.  And some websites leak really badly.

Also try setting javascript.options.mem.log to true and open Tools->Web Developer->Error Console and look at Messages, and copy/paste those values into the bug when you see this (especially if they occasionally get large when it 'jerks').
Whiteboard: READ COMMENT 39 BEFORE COMMENTING → READ COMMENT 39 BEFORE COMMENTING [memshrink][snappy]
Whiteboard: READ COMMENT 39 BEFORE COMMENTING [memshrink][snappy] → READ COMMENT 39 BEFORE COMMENTING [memshrink]
Attached file regarding comment 284 —
Please check contents in order to find out which add-on is leaking so much memory.
Attachment #575862 - Attachment mime type: text/plain → application/zip
I still get those memory leaks (with in turn periodically hanging UI) with FF9 on XP.

At the moment, FF uses like 600MB for 11 tabs. After restarting (or doing a "trim on minimize"), it uses only 60MB for the same 11 tabs. After scrolling half a meter on this page, it is back at 400MB, and scrolling (or entering text) starts to get the hiccups again (stops every few seconds for a fraction of a second).

Here's a WebGL page where this FF problem is especially disturbing because of the smooth movements that are disrupted:
http://helloracer.com/webgl/

Also, FF still is not even able to show a single stu*id animated gif fluidly:
http://www.donationcoder.com/forum/useravatars/avatar_166451.gif

I'd really like to believe that this is due to an add-on (which it probably is, because the problem seems to be absent with an empty profile). However, I already have disabled all my add-ons, then re-enabled them one by one on a day-after-day basis, but still could not find out which one could be the culprit here. 

Therefore, I hope that someone can read this information from my attached configuration files!

Regards David.P
Attachment #575862 - Attachment mime type: application/zip → application/x-zip-compressed
(In reply to David.P from comment #285)
> Also, FF still is not even able to show a single stu*id animated gif fluidly:
> http://www.donationcoder.com/forum/useravatars/avatar_166451.gif

That's bug 666446, which has been fixed on mozilla-central (Firefox 11) :-)
Ed, I don't think his smoothness issue with the gif here is bug 666446 - from looking at his gif, I'd guess that the lack of smoothness he's seeing is CC and GC pauses on the main thread.  (Hard to tell for sure without a better description of what he's seeing.)  I suspect it animates with a short period; I forget the current limit, but for many years the lower limit for GIF anims was 100ms (search closed bugs here for examples, or look earlier in this bug - I think at comments I made).  Even if it's 100ms, a 100ms GC pause could cause visible glitching.  A 250ms CC or GC pause would cause very visible glitching.

In any case, the gif issue should be a separate bug.
The GIF issue is probably separate; I noticed when moving from 3 to 4 that animated GIF speed dropped significantly, based on a particular forum that generates a page full of stupid animated GIFs. Clearly in v4 upwards (still seeing this problem) GIFs are taking more power to render. (I'm glad that it's being looked into, as it's annoying having that page consume all my CPU if I leave that tab focused ;-)

I doubt that it relates to the periodic hang problem.
Guys, the GIF performance issue that is discussed HERE is not related to bug #666446. Rather, here the GIF issue is one of the many ways in which the present bug still expresses itself:

"Firefox periodically becomes unresponsive/freezes: video jerks/pauses/halts; links, tabs, menus stop responding"

In the present bug, the entire Firefox [contents and GUI] rendering system is affected in such a way that keyboard input, menus, video, animations, scrolling etc.pp. periodically become unresponsive/freeze/jerk/pause/halt.

Thus it would be great if someone would look at the config snapshots at comment #284 / comment #285 that have been made with Firefox v9 in such periodic jerk/pause/halt/freeze state.
Whiteboard: READ COMMENT 39 BEFORE COMMENTING [memshrink] → READ COMMENT 39 BEFORE COMMENTING
about:memory and about:support for Fx8 using ~1.3GB of memory on 19 windows
I've decided to upload my case since I'm one of the original reporters and although the problem has been absent on my Fx for a while, it seems it's popping up again.

This is on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 on the release channel. I think Fx4 from the release channel was a clean install. I have not removed any add-ons since so it's a pretty stable installation I'd say.

A usage of ~1.3 gigs of mem on 19 windows (after surfing a while) seems strange. Perhaps it is of value to have about:support also record how long Fx has been running.

Perhaps the file I've just attached gives a bit 'cleaner' look (less windows open) at a situation where short pauses occur quite frequently. I would say perhaps even every 2 to 10 seconds, a pause for maybe 1/3rd of a second occurs.

The document in about:memory that has almost 1/3rd of the allocated memory, is a surprisingly simple gdocs document with about 10 pages and nothing but text. No pictures, attachments, imports.

In addition to the short pauses, I also experience a complete 30-second (or so) lock up of Fx about once an hour that I cannot explain yet. I emphasize that that is most certainly a different bug that I will start searching for in a few moments, but I just want to mention it for the sake of completeness.
Version: 3.5 Branch → 8 Branch
I think bug 667250 https://bugzilla.mozilla.org/show_bug.cgi?id=667250 might be related to this bug.
Nice one:

Firefox 8.0.
Memory footprint of 330 MB with just one single empty tab opened!!!
Performance lazy like hell !
You may see two "zombie" compartments - actually, related tabs were already closed!
You may also see huge "heap-unclassified".


Main Process

Explicit Allocations
333.34 MB (100.0%) -- explicit
├──161.25 MB (48.37%) -- heap-unclassified
├──114.02 MB (34.21%) -- js
│  ├───86.40 MB (25.92%) -- compartment([System Principal], 0x695f800)
│  │   ├──55.84 MB (16.75%) -- gc-heap
│  │   │  ├──30.36 MB (09.11%) -- objects
│  │   │  ├──12.23 MB (03.67%) -- shapes
│  │   │  ├───8.13 MB (02.44%) -- xml
│  │   │  ├───3.69 MB (01.11%) -- strings
│  │   │  └───1.43 MB (00.43%) -- (3 omitted)
│  │   ├───9.98 MB (02.99%) -- string-chars
│  │   ├───7.69 MB (02.31%) -- mjit-code
│  │   ├───5.72 MB (01.72%) -- scripts
│  │   ├───2.90 MB (00.87%) -- object-slots
│  │   ├───2.41 MB (00.72%) -- property-tables
│  │   └───1.85 MB (00.56%) -- (3 omitted)
│  ├────5.98 MB (01.80%) -- compartment(http://wn.com/zakazane_parodie_reklam)
│  │    ├──3.03 MB (00.91%) -- gc-heap
│  │    │  ├──1.89 MB (00.57%) -- arena-unused
│  │    │  └──1.14 MB (00.34%) -- (5 omitted)
│  │    └──2.96 MB (00.89%) -- (8 omitted)
│  ├────5.60 MB (01.68%) -- compartment(atoms)
│  │    ├──3.68 MB (01.10%) -- string-chars
│  │    └──1.93 MB (00.58%) -- gc-heap
│  │       ├──1.81 MB (00.54%) -- strings
│  │       └──0.11 MB (00.03%) -- (3 omitted)
│  ├────5.04 MB (01.51%) -- (11 omitted)
│  ├────5.04 MB (01.51%) -- gc-heap-chunk-dirty-unused
│  ├────3.83 MB (01.15%) -- compartment(https://www.google.com/search?q=era+omni...)
│  │    └──3.83 MB (01.15%) -- (8 omitted)
│  └────2.13 MB (00.64%) -- runtime
│       ├──2.00 MB (00.60%) -- atoms-table
│       └──0.13 MB (00.04%) -- (1 omitted)
├───53.79 MB (16.14%) -- storage
│   └──53.79 MB (16.14%) -- sqlite
│      ├──52.24 MB (15.67%) -- places.sqlite
│      │  ├──51.99 MB (15.60%) -- cache-used [4]
│      │  └───0.25 MB (00.08%) -- (2 omitted)
│      ├───3.62 MB (01.08%) -- urlclassifier3.sqlite
│      │   ├──3.54 MB (01.06%) -- cache-used
│      │   └──0.08 MB (00.02%) -- (2 omitted)
│      ├───1.81 MB (00.54%) -- zotero.sqlite
│      │   └──1.81 MB (00.54%) -- (3 omitted)
│      └──-3.87 MB (-1.16%) -- (11 omitted)
├────2.22 MB (00.67%) -- (5 omitted)
└────2.05 MB (00.62%) -- layout
     └──2.05 MB (00.62%) -- (2 omitted)

Other Measurements
  0.24 MB -- gfx-d2d-surfacecache
  5.93 MB -- gfx-d2d-surfacevram
  0.40 MB -- gfx-surface-image
  0.00 MB -- gfx-surface-win32
319.71 MB -- heap-allocated
333.96 MB -- heap-committed
  3.88 MB -- heap-dirty
 47.29 MB -- heap-unallocated
        2 -- js-compartments-system
       23 -- js-compartments-user
 70.00 MB -- js-gc-heap
  4.53 MB -- js-gc-heap-arena-unused
  0.00 MB -- js-gc-heap-chunk-clean-unused
  5.04 MB -- js-gc-heap-chunk-dirty-unused
   13.66% -- js-gc-heap-unused-fraction
398.87 MB -- private
469.07 MB -- resident
  0.95 MB -- shmem-allocated
  0.95 MB -- shmem-mapped
769.41 MB -- vsize



  Application Basics

        Name
        Firefox

        Version
        8.0

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

        Crash Reports

          about:crashes

  Extensions

        Name

        Version

        Enabled

        ID

        Adblock Plus
        1.3.10
        true
        {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

        AVG Safe Search
        12.0.0.1865
        true
        {1E73965B-8B48-48be-9C8D-68B920ABC1C4}

        Charles Autoconfiguration
        3.6.2
        true
        {3e9a3920-1b27-11da-8cd6-0800200c9a66}

        CoolPreviews
        3.5
        true
        {CE6E6E3B-84DD-4cac-9F63-8D2AE4F30A4B}

        DOM Inspector
        2.0.10
        true
        inspector@mozilla.org

        Download Statusbar
        0.9.10
        true
        {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}

        Element Hiding Helper for Adblock Plus
        1.1.2
        true
        elemhidehelper@adblockplus.org

        Firebug
        1.8.4
        true
        firebug@software.joehewitt.com

        Firecookie
        1.4
        true
        firecookie@janodvarko.cz

        FireFTP
        2.0
        true
        {a7c6cf7f-112c-4500-a7ea-39801a327e5f}

        FireFTP button
        1.1.1d
        true
        {9BAE5926-8513-417d-8E47-774955A7C60D}

        Flagfox
        4.1.9
        true
        {1018e4d6-728f-4b20-ad56-37578a4de76b}

        Greasemonkey
        0.9.13
        true
        {e4a8a97b-f2ed-450b-b12d-ee082ba24781}

        IDM CC
        7.3.10
        true
        mozilla_cc@internetdownloadmanager.com

        Illuminations for Developers
        1.1.10
        true
        sroussey@illumination-for-developers.com

        Open Bookmarks in New Tab
        0.1.2010043001
        true
        openbookmarkintab@piro.sakura.ne.jp

        Password Exporter
        1.2.1
        true
        {B17C1C5A-04B1-11DB-9804-B622A1EF5492}

        Polski slownik poprawnej pisowni
        1.0.20110621
        true
        pl@dictionaries.addons.mozilla.org

        Qualys BrowserCheck
        1.3.41.1
        true
        {7D2FB79E-E58C-4DB5-A36F-AC1C73967F4D}

        Slashy
        1.8.0
        true
        slashy@gemal.dk

        SmartWhois Launcher
        1.20
        true
        {45925a5c-e3de-447f-bed2-ded87acae111}

        Torbutton
        1.4.4.1
        true
        {e0204bd5-9d31-402b-a99d-a6aa8ffebdca}

        Web Developer
        1.1.9
        true
        {c45c406e-ab73-11d8-be73-000a95be3b12}

        Webvision Plugin
        1.0.0.21
        true
        webvision@trinigy.net

        Zotero
        2.1.10
        true
        zotero@chnm.gmu.edu

        Aardvark
        3.0
        false
        aardvark@rob.brown

        Adobe Contribute Toolbar
        5.0
        false
        {01A8CA0A-4C96-465b-A49B-65C46FAD54F9}

        BarTab
        2.0
        false
        bartap@philikon.de

        CGPersia Toolbar
        0.1b
        false
        cgpersiatoolbar@stefanobolli.it

        EventBug
        0.1b9
        false
        eventbug@getfirebug.com

        FireDiff
        1.1.4
        false
        firediff@johnjbarton.com

        IE Tab
        1.5.20090525
        false
        {77b819fa-95ad-4f2c-ac7c-486b356188a9}

        Microsoft .NET Framework Assistant
        1.2.1
        false
        {20a82645-c095-46ed-80e3-08825760534b}

        Skype Click to Call
        5.6.0.8442
        false
        {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A}

        Sothink SWF Catcher
        1.4
        false
        {618D522B-652C-4e19-9194-048700B12ED6}

        Vividas player plugin
        4.1.0
        false
        player@vividas.com

        Window Resizer
        1.0
        false
        {C1273352-9340-4d54-A6D7-17DC157EC0B9}

        Yet Another Smooth Scrolling
        3.0.19
        false
        yetanothersmoothscrolling@kataho

        Zend Studio Toolbar
        2.4
        false
        {3c9761ad-a43d-4447-b924-f5d83cb48063}

  Modified Preferences

      Name

      Value

        accessibility.typeaheadfind
        true

        accessibility.typeaheadfind.flashBar
        0

        browser.history_expire_days.mirror
        180

        browser.places.importBookmarksHTML
        false

        browser.places.importDefaults
        false

        browser.places.leftPaneFolderId
        -1

        browser.places.migratePostDataAnnotations
        false

        browser.places.smartBookmarksVersion
        2

        browser.places.updateRecentTagsUri
        false

        browser.startup.homepage
        http://my.daemon-search.com/|http://www.google.pl/

        browser.startup.homepage_override.buildID
        20111104165243

        browser.startup.homepage_override.mstone
        rv:8.0

        dom.max_script_run_time
        1800

        extensions.lastAppVersion
        8.0

        font.minimum-size.x-western
        10

        font.name.serif.x-western
        Verdana

        font.size.variable.x-western
        12

        general.useragent.extra.microsoftdotnet
        ( .NET CLR 3.5.30729; .NET4.0E)

        network.cookie.prefsMigrated
        true

        network.security.ports.banned
        8118,8123,9050,9051

        places.database.lastMaintenance
        1323324740

        places.history.expiration.transient_current_max_pages
        257672

        places.last_vacuum
        1295667705

        plugin.disable_full_page_plugin_for_types
        audio/AMR,application/sdp,application/x-sdp

        print.print_bgcolor
        false

        print.print_bgimages
        false

        print.print_command

        print.print_downloadfonts
        false

        print.print_evenpages
        true

        print.print_in_color
        true

        print.print_margin_bottom
        0.5

        print.print_margin_left
        0.5

        print.print_margin_right
        0.5

        print.print_margin_top
        0.5

        print.print_oddpages
        true

        print.print_orientation
        0

        print.print_pagedelay
        500

        print.print_paper_data
        0

        print.print_paper_height
        11.00

        print.print_paper_size_type
        1

        print.print_paper_size_unit
        0

        print.print_paper_width
        8.50

        print.print_printer
        EPSON Stylus Photo RX585 Series

        print.print_reversed
        false

        print.print_scaling
        1.00

        print.print_shrink_to_fit
        true

        print.print_to_file
        false

        print.print_unwriteable_margin_bottom
        0

        print.print_unwriteable_margin_left
        0

        print.print_unwriteable_margin_right
        0

        print.print_unwriteable_margin_top
        0

        print.printer_Adobe_PDF.print_bgcolor
        false

        print.printer_Adobe_PDF.print_bgimages
        false

        print.printer_Adobe_PDF.print_command

        print.printer_Adobe_PDF.print_downloadfonts
        false

        print.printer_Adobe_PDF.print_edge_bottom
        0

        print.printer_Adobe_PDF.print_edge_left
        0

        print.printer_Adobe_PDF.print_edge_right
        0

        print.printer_Adobe_PDF.print_edge_top
        0

        print.printer_Adobe_PDF.print_evenpages
        true

        print.printer_Adobe_PDF.print_footercenter

        print.printer_Adobe_PDF.print_footerleft
        &PT

        print.printer_Adobe_PDF.print_footerright
        &D

        print.printer_Adobe_PDF.print_headercenter

        print.printer_Adobe_PDF.print_headerleft
        &T

        print.printer_Adobe_PDF.print_headerright
        &U

        print.printer_Adobe_PDF.print_in_color
        true

        print.printer_Adobe_PDF.print_margin_bottom
        0.5

        print.printer_Adobe_PDF.print_margin_left
        0.5

        print.printer_Adobe_PDF.print_margin_right
        0.5

        print.printer_Adobe_PDF.print_margin_top
        0.5

        print.printer_Adobe_PDF.print_oddpages
        true

        print.printer_Adobe_PDF.print_orientation
        0

        print.printer_Adobe_PDF.print_pagedelay
        500

        print.printer_Adobe_PDF.print_paper_data
        9

        print.printer_Adobe_PDF.print_paper_height
        11.00

        print.printer_Adobe_PDF.print_paper_size_type
        0

        print.printer_Adobe_PDF.print_paper_size_unit
        1

        print.printer_Adobe_PDF.print_paper_width
        8.50

        print.printer_Adobe_PDF.print_reversed
        false

        print.printer_Adobe_PDF.print_scaling
        1.00

        print.printer_Adobe_PDF.print_shrink_to_fit
        true

        print.printer_Adobe_PDF.print_to_file
        false

        print.printer_Adobe_PDF.print_unwriteable_margin_bottom
        0

        print.printer_Adobe_PDF.print_unwriteable_margin_left
        0

        print.printer_Adobe_PDF.print_unwriteable_margin_right
        0

        print.printer_Adobe_PDF.print_unwriteable_margin_top
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_bgcolor
        false

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_bgimages
        false

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_command

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_downloadfonts
        false

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_edge_bottom
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_edge_left
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_edge_right
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_edge_top
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_evenpages
        true

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_footercenter

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_footerleft
        &PT

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_footerright
        &D

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_headercenter

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_headerleft
        &T

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_headerright
        &U

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_in_color
        true

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_margin_bottom
        1.57500004768372

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_margin_left
        0.5

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_margin_right
        0.5

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_margin_top
        0.5

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_oddpages
        true

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_orientation
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_page_delay
        50

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_pagedelay
        500

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_paper_data
        9

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_paper_height
        11.00

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_paper_size_type
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_paper_size_unit
        1

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_paper_width
        8.50

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_reversed
        false

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_scaling
        1.00

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_shrink_to_fit
        true

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_to_file
        false

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_unwriteable_margin_bottom
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_unwriteable_margin_left
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_unwriteable_margin_right
        0

        print.printer_EPSON_Stylus_Photo_RX585_Series.print_unwriteable_margin_top
        0

        print.printer_Microsoft_XPS_Document_Writer.print_bgcolor
        false

        print.printer_Microsoft_XPS_Document_Writer.print_bgimages
        false

        print.printer_Microsoft_XPS_Document_Writer.print_command

        print.printer_Microsoft_XPS_Document_Writer.print_downloadfonts
        false

        print.printer_Microsoft_XPS_Document_Writer.print_evenpages
        true

        print.printer_Microsoft_XPS_Document_Writer.print_footercenter

        print.printer_Microsoft_XPS_Document_Writer.print_footerleft
        &PT

        print.printer_Microsoft_XPS_Document_Writer.print_footerright
        &D

        print.printer_Microsoft_XPS_Document_Writer.print_headercenter

        print.printer_Microsoft_XPS_Document_Writer.print_headerleft
        &T

        print.printer_Microsoft_XPS_Document_Writer.print_headerright
        &U

        print.printer_Microsoft_XPS_Document_Writer.print_in_color
        true

        print.printer_Microsoft_XPS_Document_Writer.print_margin_bottom
        0.5

        print.printer_Microsoft_XPS_Document_Writer.print_margin_left
        0.5

        print.printer_Microsoft_XPS_Document_Writer.print_margin_right
        0.5

        print.printer_Microsoft_XPS_Document_Writer.print_margin_top
        0.5

        print.printer_Microsoft_XPS_Document_Writer.print_oddpages
        true

        print.printer_Microsoft_XPS_Document_Writer.print_orientation
        0

        print.printer_Microsoft_XPS_Document_Writer.print_pagedelay
        500

        print.printer_Microsoft_XPS_Document_Writer.print_paper_data
        9

        print.printer_Microsoft_XPS_Document_Writer.print_paper_height
        11.00

        print.printer_Microsoft_XPS_Document_Writer.print_paper_size
        0

        print.printer_Microsoft_XPS_Document_Writer.print_paper_size_type
        0

        print.printer_Microsoft_XPS_Document_Writer.print_paper_size_unit
        1

        print.printer_Microsoft_XPS_Document_Writer.print_paper_width
        8.50

        print.printer_Microsoft_XPS_Document_Writer.print_reversed
        false

        print.printer_Microsoft_XPS_Document_Writer.print_scaling
        1.00

        print.printer_Microsoft_XPS_Document_Writer.print_shrink_to_fit
        true

        print.printer_Microsoft_XPS_Document_Writer.print_to_file
        false

        print.printer_PDF-XChange_4.0.print_bgcolor
        false

        print.printer_PDF-XChange_4.0.print_bgimages
        false

        print.printer_PDF-XChange_4.0.print_command

        print.printer_PDF-XChange_4.0.print_downloadfonts
        false

        print.printer_PDF-XChange_4.0.print_edge_bottom
        0

        print.printer_PDF-XChange_4.0.print_edge_left
        0

        print.printer_PDF-XChange_4.0.print_edge_right
        0

        print.printer_PDF-XChange_4.0.print_edge_top
        0

        print.printer_PDF-XChange_4.0.print_evenpages
        true

        print.printer_PDF-XChange_4.0.print_footercenter

        print.printer_PDF-XChange_4.0.print_footerleft
        &PT

        print.printer_PDF-XChange_4.0.print_footerright
        &D

        print.printer_PDF-XChange_4.0.print_headercenter

        print.printer_PDF-XChange_4.0.print_headerleft
        &T

        print.printer_PDF-XChange_4.0.print_headerright
        &U

        print.printer_PDF-XChange_4.0.print_in_color
        true

        print.printer_PDF-XChange_4.0.print_margin_bottom
        0.5

        print.printer_PDF-XChange_4.0.print_margin_left
        0.5

        print.printer_PDF-XChange_4.0.print_margin_right
        0.5

        print.printer_PDF-XChange_4.0.print_margin_top
        0.5

        print.printer_PDF-XChange_4.0.print_oddpages
        true

        print.printer_PDF-XChange_4.0.print_orientation
        0

        print.printer_PDF-XChange_4.0.print_pagedelay
        500

        print.printer_PDF-XChange_4.0.print_paper_data
        9

        print.printer_PDF-XChange_4.0.print_paper_height
        11.00

        print.printer_PDF-XChange_4.0.print_paper_size_type
        0

        print.printer_PDF-XChange_4.0.print_paper_size_unit
        1

        print.printer_PDF-XChange_4.0.print_paper_width
        8.50

        print.printer_PDF-XChange_4.0.print_reversed
        false

        print.printer_PDF-XChange_4.0.print_scaling
        1.00

        print.printer_PDF-XChange_4.0.print_shrink_to_fit
        true

        print.printer_PDF-XChange_4.0.print_to_file
        false

        print.printer_PDF-XChange_4.0.print_unwriteable_margin_bottom
        0

        print.printer_PDF-XChange_4.0.print_unwriteable_margin_left
        0

        print.printer_PDF-XChange_4.0.print_unwriteable_margin_right
        0

        print.printer_PDF-XChange_4.0.print_unwriteable_margin_top
        0

        privacy.clearOnShutdown.cookies
        false

        privacy.clearOnShutdown.history
        false

        privacy.clearOnShutdown.offlineApps
        true

        privacy.clearOnShutdown.sessions
        false

        privacy.cpd.cookies
        false

        privacy.cpd.downloads
        false

        privacy.cpd.formdata
        false

        privacy.cpd.history
        false

        privacy.cpd.sessions
        false

        privacy.item.history
        false

        privacy.item.offlineApps
        true

        privacy.item.sessions
        false

        privacy.sanitize.migrateFx3Prefs
        true

        privacy.sanitize.timeSpan
        0

        security.warn_viewing_mixed
        false

  Graphics

        Adapter Description
        NVIDIA GeForce GTX 285

        Vendor ID
        10de

        Device ID
        05e3

        Adapter RAM
        1024

        Adapter Drivers
        nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

        Driver Version
        8.17.12.8562

        Driver Date
        10-15-2011

        Adapter RAM (GPU #2)
        Unknown

        Adapter Drivers (GPU #2)
        Unknown

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        DISPLAY1 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 200 ] DISPLAY2 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 50 ]

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU Accelerated Windows
        1/1 Direct3D 10

    Enabled plugins
Find more information about browser plugins at mozilla.org.
Find updates for installed plugins at mozilla.com/plugincheck.
Help for installing plugins is available from plugindoc.mozdev.org.
Qualys BrowserCheck Plugin

    File: npqbc.dll
    Version: 1.3.41.1
    Qualys BrowserCheck Plugin 1.3.41.1

MIME Type 	Description 	Suffixes
application/qualys-browser-check-plugin 		
Webvision Plugin

    File: npvision.dll
    Version: 1.0.0.21
    Vision Scene Plugin

MIME Type 	Description 	Suffixes
application/x-vscene 	Exported Vision Scene 	vmanifest
Shockwave for Director

    File: np32dsw.dll
    Version: 11.6.3.633
    Adobe Shockwave for Director Netscape plug-in, version 11.6.3.633

MIME Type 	Description 	Suffixes
application/x-director 	Shockwave Movie 	dir,dxr,dcr
Shockwave Flash

    File: NPSWF32.dll
    Version: 11.1.102.55
    Shockwave Flash 11.1 r102

MIME Type 	Description 	Suffixes
application/x-shockwave-flash 	Adobe Flash movie 	swf
application/futuresplash 	FutureSplash movie 	spl
QuickTime Plug-in 7.7.1

    File: npqtplugin7.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
image/x-targa 	obrazek TGA 	targa,tga
image/jp2 	obrazek JPEG2000 	jp2
image/jpeg2000 	obrazek JPEG2000 	jp2
image/jpeg2000-image 	obrazek JPEG2000 	jp2
image/x-jpeg2000-image 	obrazek JPEG2000 	jp2
QuickTime Plug-in 7.7.1

    File: npqtplugin6.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
video/x-m4v 	Wideo (zabezpieczone) 	m4v
image/x-macpaint 	obrazek MacPaint 	pntg,pnt,mac
image/pict 	obrazek PICT 	pict,pic,pct
image/x-pict 	obrazek PICT 	pict,pic,pct
image/png 	PNG image 	png
image/x-png 	PNG image 	png
image/x-quicktime 	obrazek QuickTime 	qtif,qti
image/x-sgi 	obrazek SGI 	sgi,rgb
QuickTime Plug-in 7.7.1

    File: npqtplugin5.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
audio/3gpp 	media 3GPP 	3gp,3gpp
video/3gpp2 	media 3GPP2 	3g2,3gp2
audio/3gpp2 	media 3GPP2 	3g2,3gp2
video/sd-video 	wideo SD 	sdv
application/x-mpeg 	noĹ nik AMC 	amc
video/mp4 	noĹ nik MPEG-4 	mp4
audio/mp4 	noĹ nik MPEG-4 	mp4
audio/x-m4a 	audio AAC 	m4a
audio/x-m4p 	audio AAC (zabezpieczony) 	m4p
audio/x-m4b 	ksiłřka audio AAC 	m4b
QuickTime Plug-in 7.7.1

    File: npqtplugin4.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
video/mpeg 	noĹ nik MPEG 	mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa
audio/mpeg 	audio MPEG 	mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a
audio/x-mpeg 	audio MPEG 	mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a
video/3gpp 	media 3GPP 	3gp,3gpp
QuickTime Plug-in 7.7.1

    File: npqtplugin3.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
audio/x-gsm 	audio GSM 	gsm
audio/AMR 	audio AMR 	AMR
audio/aac 	audio AAC 	aac,adts
audio/x-aac 	audio AAC 	aac,adts
audio/x-caf 	audio CAF 	caf
audio/ac3 	audio AC3 	ac3
audio/x-ac3 	audio AC3 	ac3
video/x-mpeg 	noĹ nik MPEG 	mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa
QuickTime Plug-in 7.7.1

    File: npqtplugin2.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
audio/aiff 	audio AIFF 	aiff,aif,aifc,cdda
audio/x-aiff 	audio AIFF 	aiff,aif,aifc,cdda
audio/basic 	audio uLaw/AU 	au,snd,ulw
audio/mid 	MIDI 	mid,midi,smf,kar
audio/x-midi 	MIDI 	mid,midi,smf,kar
audio/midi 	MIDI 	mid,midi,smf,kar
audio/vnd.qcelp 	QUALCOMM PureVoice audio 	qcp
QuickTime Plug-in 7.7.1

    File: npqtplugin.dll
    Version: 7.7.1.0
    The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.

MIME Type 	Description 	Suffixes
application/sdp 	deskryptor strumienia SDP 	sdp
application/x-sdp 	deskryptor strumienia SDP 	sdp
application/x-rtsp 	deskryptor strumienia RTSP 	rtsp,rts
video/quicktime 	QuickTime Movie 	mov,qt,mqv
video/flc 	AutoDesk Animator (FLC) 	flc,fli,cel
audio/x-wav 	audio WAVE 	wav,bwf
audio/wav 	audio WAVE 	wav,bwf
Google Update

    File: npGoogleUpdate3.dll
    Version: 1.3.21.79
    Google Update

MIME Type 	Description 	Suffixes
application/x-vnd.google.update3webcontrol.3 		
application/x-vnd.google.oneclickctrl.9 		
Google Earth Plugin

    File: npgeplugin.dll
    Version: 6.1.0.5001
    GEPlugin

MIME Type 	Description 	Suffixes
application/geplugin 	GEPlugin 	
NVIDIA 3D VISION

    File: npnv3dvstreaming.dll
    Version: 7.17.12.8562
    NVIDIA 3D Vision Streaming plugin for Mozilla browsers

MIME Type 	Description 	Suffixes
application/mozilla-3DV-streaming-plugin 	npnv3dvstreaming 	rts
NVIDIA 3D Vision

    File: npnv3dv.dll
    Version: 7.17.12.8562
    NVIDIA 3D Vision plugin for Mozilla browsers

MIME Type 	Description 	Suffixes
image/jps 	JPEG-based stereo image 	jps
image/pns 	PNG-based stereo image 	pns
image/mpo 	Multi-Picture Format image 	mpo
ActiveTouch General Plugin Container

    File: npatgpc.dll
    Version: 27.27.2011.408
    ActiveTouch General Plugin Container Version 105

MIME Type 	Description 	Suffixes
application/x-atgpc-plugin 	General Plugin Container File 	gpc
Adobe Acrobat

    File: nppdf32.dll
    Version: 10.1.1.33
    Adobe PDF Plug-In For Firefox and Netscape 10.1.1

MIME Type 	Description 	Suffixes
application/pdf 	Acrobat Portable Document Format 	pdf
application/vnd.adobe.pdfxml 	Adobe PDF in XML Format 	pdfxml
application/vnd.adobe.x-mars 	Adobe PDF in XML Format 	mars
application/vnd.fdf 	Acrobat Forms Data Format 	fdf
application/vnd.adobe.xfdf 	XML Version of Acrobat Forms Data Format 	xfdf
application/vnd.adobe.xdp+xml 	Acrobat XML Data Package 	xdp
application/vnd.adobe.xfd+xml 	Adobe FormFlow99 Data File 	xfd
Silverlight Plug-In

    File: npctrl.dll
    Version: 4.0.60831.0
    4.0.60831.0

MIME Type 	Description 	Suffixes
application/x-silverlight 	npctrl 	scr
application/x-silverlight-2 		
Unity Player

    File: npUnity3D32.dll
    Version: 3.4.0.27242
    Unity Player 3.4.0f5

MIME Type 	Description 	Suffixes
application/vnd.unity 	Unity Player datafile 	unity3d
Winamp Application Detector

    File: npwachk.dll
    Version: 5.6.2.3173
    Winamp Application Detector

MIME Type 	Description 	Suffixes
application/x-winampx-1.0.0.1 	winamp 	
Java Deployment Toolkit 6.0.260.3

    File: npdeployJava1.dll
    Version: 6.0.260.3
    NPRuntime Script Plug-in Library for Java(TM) Deploy

MIME Type 	Description 	Suffixes
application/java-deployment-toolkit 		
Java(TM) Platform SE 6 U26

    File: npjp2.dll
    Version: 6.0.260.3
    Next Generation Java Plug-in 1.6.0_26 for Mozilla browsers

MIME Type 	Description 	Suffixes
application/x-java-applet 	Java Applet 	
application/x-java-bean 	JavaBeans 	
application/x-java-vm 		
application/x-java-applet;version=1.1.1 		
application/x-java-bean;version=1.1.1 		
application/x-java-applet;version=1.1 		
application/x-java-bean;version=1.1 		
application/x-java-applet;version=1.2 		
application/x-java-bean;version=1.2 		
application/x-java-applet;version=1.1.3 		
application/x-java-bean;version=1.1.3 		
application/x-java-applet;version=1.1.2 		
application/x-java-bean;version=1.1.2 		
application/x-java-applet;version=1.3 		
application/x-java-bean;version=1.3 		
application/x-java-applet;version=1.2.2 		
application/x-java-bean;version=1.2.2 		
application/x-java-applet;version=1.2.1 		
application/x-java-bean;version=1.2.1 		
application/x-java-applet;version=1.3.1 		
application/x-java-bean;version=1.3.1 		
application/x-java-applet;version=1.4 		
application/x-java-bean;version=1.4 		
application/x-java-applet;version=1.4.1 		
application/x-java-bean;version=1.4.1 		
application/x-java-applet;version=1.4.2 		
application/x-java-bean;version=1.4.2 		
application/x-java-applet;version=1.5 		
application/x-java-bean;version=1.5 		
application/x-java-applet;version=1.6 		
application/x-java-bean;version=1.6 		
application/x-java-applet;jpi-version=1.6.0_26 		
application/x-java-bean;jpi-version=1.6.0_26 		
WPI Detector 1.4

    File: NPWPIDetector.dll
    Version: 1.1.0.4
    wpidetector

MIME Type 	Description 	Suffixes
application/wpi-plugin 		
Vividas Player Plugin

    File: npVividasPlayer.dll
    Version: 4.0.0.0
    Vividas Player Plugin

MIME Type 	Description 	Suffixes
application/x-vividas-player 	Vividas Player Plugin 	
application/x-vividas-player;version=4.0 		
Windows Live Photo Gallery

    File: NPWLPG.dll
    Version: 15.4.3508.1109
    NPWLPG

MIME Type 	Description 	Suffixes
application/x-wlpg3-detect 	Windows Live Photo Gallery 	wlpg
application/x-wlpg-detect 	Windows Live Photo Gallery 	wlpg
Microsoft Office Live Plug-in for Firefox

    File: npOLW.dll
    Version: 2.0.4024.1
    Office Live Update v1.5

MIME Type 	Description 	Suffixes
application/OfficeLive 	Office Live Update v1.5 	
ShiVa3D Plugin 1.8.1

    File: npShiVa3D_1.8.1.dll
    Version: 1.8.1.0
    ShiVa3D Plugin 1,8,1,1 for 3D real-time applications made with ShiVa Editor.

MIME Type 	Description 	Suffixes
application/x-shiva3d-1.8 	ShiVa3D File 	stk
Octoshape Streaming Services

    File: npoctoshape.dll
    Version: 20000.9.928.0
    Octoshape embedded video plugin

MIME Type 	Description 	Suffixes
application/x-octoshapeplugin-client 	Octoshape Streaming Services 	
3DVIA player

    File: npvirtools.dll
    Version: 5.0.0.12
    3DVIA player(5.0.0.12). For more information, visit the 3DVIA player web site.

MIME Type 	Description 	Suffixes
application/x-virtools 	Virtools Composition 	cmo
application/x-nemo 	Virtools Composition 	cmo
application/x-virtools 	Virtools Web Player File 	vmo
BitCometAgent

    File: npBitCometAgent.dll
    Version: 1.7.7.16
    BitCometAgent v1.07 for Firefox

MIME Type 	Description 	Suffixes
application/bitcomet-agent 		
Windows Genuine Advantage

    File: npLegitCheckPlugin.dll
    Version: 1.9.42.0
    1.9.0042.0

MIME Type 	Description 	Suffixes
application/WGA-plugin 	npLegitCheckPlugin 	*
Adobe Contribute CS4

    File: npContribute.dll
    Version: 5.0.0.3264
    Contribute Firefox IBE Plugin DLL

MIME Type 	Description 	Suffixes
application/ibe 	Contribute Firefox IBE Plugin DLL 	ibe
Microsoft® Windows Media Player Firefox Plugin

    File: np-mswmp.dll
    Version: 1.0.0.8
    np-mswmp

MIME Type 	Description 	Suffixes
application/x-ms-wmp 	np-mswmp 	*
application/asx 		*
video/x-ms-asf-plugin 		*
application/x-mplayer2 		*
video/x-ms-asf 		asf,asx,*
video/x-ms-wm 		wm,*
audio/x-ms-wma 		wma,*
audio/x-ms-wax 		wax,*
video/x-ms-wmv 		wmv,*
video/x-ms-wvx 		wvx,*
Yet, just an hour later - again just a single empty tab opened. Roughly after 10 minutes after browser restart and browsing a few pages:

Main Process

Explicit Allocations
410,978,128 B (100.0%) -- explicit
├──159,647,859 B (38.85%) -- js
│  ├───92,726,514 B (22.56%) -- compartment([System Principal], 0x6250000)
│  │   ├──49,364,992 B (12.01%) -- gc-heap
│  │   │  ├──22,199,536 B (05.40%) -- objects
│  │   │  ├──12,600,448 B (03.07%) -- arena-unused
│  │   │  ├───8,669,920 B (02.11%) -- shapes
│  │   │  ├───3,066,192 B (00.75%) -- strings
│  │   │  ├───2,370,744 B (00.58%) -- xml
│  │   │  ├─────265,320 B (00.06%) -- arena-padding
│  │   │  └─────192,832 B (00.05%) -- arena-headers
│  │   ├──13,303,808 B (03.24%) -- mjit-code
│  │   ├──13,247,908 B (03.22%) -- scripts
│  │   ├───6,800,224 B (01.65%) -- object-slots
│  │   ├───4,323,432 B (01.05%) -- property-tables
│  │   ├───3,453,594 B (00.84%) -- string-chars
│  │   ├───1,863,364 B (00.45%) -- mjit-data
│  │   ├─────238,120 B (00.06%) -- tjit-data
│  │   │     ├───87,464 B (00.02%) -- allocators-main
│  │   │     ├───76,656 B (00.02%) -- trace-monitor
│  │   │     └───74,000 B (00.02%) -- allocators-reserve
│  │   └─────131,072 B (00.03%) -- tjit-code
│  ├───39,605,888 B (09.64%) -- gc-heap-chunk-dirty-unused
│  ├────7,571,411 B (01.84%) -- compartment(http://streetlightblog.blogspot.com/2011/09/what-really-caused-eurozone-crisis-part.html)
│  │    ├──3,731,456 B (00.91%) -- gc-heap
│  │    │  ├──1,639,472 B (00.40%) -- arena-unused
│  │    │  ├──1,346,944 B (00.33%) -- objects
│  │    │  ├────689,320 B (00.17%) -- shapes
│  │    │  ├─────24,432 B (00.01%) -- strings
│  │    │  ├─────16,712 B (00.00%) -- arena-padding
│  │    │  └─────14,576 B (00.00%) -- arena-headers
│  │    ├──1,941,775 B (00.47%) -- scripts
│  │    ├────851,968 B (00.21%) -- mjit-code
│  │    ├────232,408 B (00.06%) -- property-tables
│  │    ├────229,872 B (00.06%) -- tjit-data
│  │    │    ├───94,512 B (00.02%) -- trace-monitor
│  │    │    ├───74,000 B (00.02%) -- allocators-reserve
│  │    │    └───61,360 B (00.01%) -- allocators-main
│  │    ├────201,592 B (00.05%) -- object-slots
│  │    ├────131,640 B (00.03%) -- mjit-data
│  │    ├────131,072 B (00.03%) -- tjit-code
│  │    └────119,628 B (00.03%) -- string-chars
│  ├────6,521,476 B (01.59%) -- compartment(atoms)
│  │    ├──4,186,756 B (01.02%) -- string-chars
│  │    └──2,334,720 B (00.57%) -- gc-heap
│  │       ├──2,034,400 B (00.50%) -- strings
│  │       ├────286,944 B (00.07%) -- arena-unused
│  │       ├──────9,120 B (00.00%) -- arena-headers
│  │       └──────4,256 B (00.00%) -- arena-padding
│  ├────3,687,703 B (00.90%) -- compartment(http://krugman.blogs.nytimes.com/2011/09/23/origins-of-the-euro-crisis/)
│  │    ├──1,609,728 B (00.39%) -- gc-heap
│  │    │  ├────874,328 B (00.21%) -- arena-unused
│  │    │  ├────449,640 B (00.11%) -- objects
│  │    │  ├────259,600 B (00.06%) -- shapes
│  │    │  ├─────13,568 B (00.00%) -- strings
│  │    │  ├──────6,304 B (00.00%) -- arena-padding
│  │    │  └──────6,288 B (00.00%) -- arena-headers
│  │    ├────786,432 B (00.19%) -- mjit-code
│  │    ├────577,203 B (00.14%) -- scripts
│  │    ├────217,752 B (00.05%) -- tjit-data
│  │    │    ├──100,464 B (00.02%) -- trace-monitor
│  │    │    ├───74,000 B (00.02%) -- allocators-reserve
│  │    │    └───43,288 B (00.01%) -- allocators-main
│  │    ├────172,448 B (00.04%) -- mjit-data
│  │    ├────131,072 B (00.03%) -- tjit-code
│  │    ├────109,436 B (00.03%) -- property-tables
│  │    ├─────55,848 B (00.01%) -- object-slots
│  │    └─────27,784 B (00.01%) -- string-chars
│  ├────3,485,827 B (00.85%) -- compartment(http://en.wikipedia.org/wiki/Capital_account)
│  │    ├──1,544,192 B (00.38%) -- gc-heap
│  │    │  ├────807,792 B (00.20%) -- arena-unused
│  │    │  ├────442,624 B (00.11%) -- objects
│  │    │  ├────270,520 B (00.07%) -- shapes
│  │    │  ├──────9,664 B (00.00%) -- strings
│  │    │  ├──────7,560 B (00.00%) -- arena-padding
│  │    │  └──────6,032 B (00.00%) -- arena-headers
│  │    ├────720,896 B (00.18%) -- mjit-code
│  │    ├────447,055 B (00.11%) -- scripts
│  │    ├────286,384 B (00.07%) -- tjit-data
│  │    │    ├──118,896 B (00.03%) -- trace-monitor
│  │    │    ├───93,488 B (00.02%) -- allocators-main
│  │    │    └───74,000 B (00.02%) -- allocators-reserve
│  │    ├────182,584 B (00.04%) -- mjit-data
│  │    ├────131,072 B (00.03%) -- tjit-code
│  │    ├─────90,600 B (00.02%) -- property-tables
│  │    ├─────69,584 B (00.02%) -- object-slots
│  │    └─────13,460 B (00.00%) -- string-chars
│  ├────2,238,464 B (00.54%) -- runtime
│  │    ├──2,097,152 B (00.51%) -- atoms-table
│  │    └────141,312 B (00.03%) -- runtime-object
│  ├────1,640,832 B (00.40%) -- gc-heap-chunk-admin
│  ├──────607,556 B (00.15%) -- compartment(about:blank)
│  │      ├──548,864 B (00.13%) -- gc-heap
│  │      │  ├──316,960 B (00.08%) -- arena-unused [12]
│  │      │  ├──124,464 B (00.03%) -- objects [12]
│  │      │  ├──103,760 B (00.03%) -- shapes [12]
│  │      │  ├────2,144 B (00.00%) -- arena-headers [12]
│  │      │  └────1,536 B (00.00%) -- arena-padding [12]
│  │      ├───47,584 B (00.01%) -- object-slots [12]
│  │      ├────9,456 B (00.00%) -- property-tables [12]
│  │      └────1,652 B (00.00%) -- scripts [12]
│  ├──────578,060 B (00.14%) -- compartment(http://www.illumination-for-developers.com/firebuganalytics/)
│  │      ├──262,144 B (00.06%) -- mjit-code
│  │      ├──192,296 B (00.05%) -- tjit-data
│  │      │  ├───95,088 B (00.02%) -- trace-monitor
│  │      │  ├───74,000 B (00.02%) -- allocators-reserve
│  │      │  └───23,208 B (00.01%) -- allocators-main
│  │      ├──110,592 B (00.03%) -- gc-heap
│  │      │  ├───41,696 B (00.01%) -- objects
│  │      │  ├───37,040 B (00.01%) -- shapes
│  │      │  ├───31,208 B (00.01%) -- arena-unused
│  │      │  ├──────432 B (00.00%) -- arena-headers
│  │      │  └──────216 B (00.00%) -- arena-padding
│  │      ├────9,760 B (00.00%) -- object-slots
│  │      ├────3,032 B (00.00%) -- property-tables
│  │      └──────236 B (00.00%) -- scripts
│  ├──────527,772 B (00.13%) -- compartment(http://platform.twitter.com/widgets/hub.html)
│  │      ├──202,632 B (00.05%) -- tjit-data
│  │      │  ├───97,392 B (00.02%) -- trace-monitor
│  │      │  ├───74,000 B (00.02%) -- allocators-reserve
│  │      │  └───31,240 B (00.01%) -- allocators-main
│  │      ├──131,072 B (00.03%) -- mjit-code
│  │      ├──131,072 B (00.03%) -- tjit-code
│  │      ├───57,344 B (00.01%) -- gc-heap
│  │      │   ├──43,576 B (00.01%) -- arena-unused
│  │      │   ├───7,960 B (00.00%) -- objects
│  │      │   ├───5,440 B (00.00%) -- shapes
│  │      │   ├─────224 B (00.00%) -- arena-headers
│  │      │   └─────144 B (00.00%) -- arena-padding
│  │      ├────4,344 B (00.00%) -- object-slots
│  │      ├────1,072 B (00.00%) -- property-tables
│  │      └──────236 B (00.00%) -- scripts
│  ├──────262,144 B (00.06%) -- stack
│  ├──────170,998 B (00.04%) -- compartment(null-principal)
│  │      ├───94,208 B (00.02%) -- gc-heap
│  │      │   ├──36,736 B (00.01%) -- arena-unused
│  │      │   ├──33,208 B (00.01%) -- objects
│  │      │   ├──23,560 B (00.01%) -- shapes
│  │      │   ├─────368 B (00.00%) -- arena-headers
│  │      │   ├─────264 B (00.00%) -- arena-padding
│  │      │   └──────72 B (00.00%) -- xml
│  │      ├───65,536 B (00.02%) -- mjit-code
│  │      ├───10,064 B (00.00%) -- object-slots
│  │      ├────1,072 B (00.00%) -- property-tables
│  │      └──────118 B (00.00%) -- scripts
│  ├───────23,214 B (00.01%) -- compartment(moz-nullprincipal:{6163a03c-c128-49bc-9fc4-475b609092c4})
│  │       ├──20,480 B (00.00%) -- gc-heap
│  │       │  ├──14,800 B (00.00%) -- arena-unused
│  │       │  ├───3,352 B (00.00%) -- objects
│  │       │  ├───2,200 B (00.00%) -- shapes
│  │       │  ├──────80 B (00.00%) -- arena-headers
│  │       │  └──────48 B (00.00%) -- arena-padding
│  │       ├───2,448 B (00.00%) -- object-slots
│  │       ├─────168 B (00.00%) -- property-tables
│  │       └─────118 B (00.00%) -- scripts
│  └────────────0 B (00.00%) -- gc-heap-chunk-clean-unused
├──146,114,188 B (35.55%) -- heap-unclassified
├───96,984,496 B (23.60%) -- storage
│   └──96,984,496 B (23.60%) -- sqlite
│      ├──87,681,024 B (21.33%) -- places.sqlite
│      │  ├──87,365,120 B (21.26%) -- cache-used [4]
│      │  ├─────267,384 B (00.07%) -- stmt-used [4]
│      │  └──────48,520 B (00.01%) -- schema-used [4]
│      ├───3,643,600 B (00.89%) -- urlclassifier3.sqlite
│      │   ├──3,559,544 B (00.87%) -- cache-used
│      │   ├─────81,392 B (00.02%) -- stmt-used
│      │   └──────2,664 B (00.00%) -- schema-used
│      ├───1,893,296 B (00.46%) -- zotero.sqlite
│      │   ├──1,232,576 B (00.30%) -- cache-used [2]
│      │   ├────659,072 B (00.16%) -- schema-used [2]
│      │   └──────1,648 B (00.00%) -- stmt-used [2]
│      ├───1,558,896 B (00.38%) -- cookies.sqlite
│      │   ├──1,546,896 B (00.38%) -- cache-used
│      │   ├─────10,160 B (00.00%) -- stmt-used
│      │   └──────1,840 B (00.00%) -- schema-used
│      ├─────710,512 B (00.17%) -- formhistory.sqlite
│      │     ├──644,224 B (00.16%) -- cache-used
│      │     ├───64,592 B (00.02%) -- stmt-used
│      │     └────1,696 B (00.00%) -- schema-used
│      ├─────455,072 B (00.11%) -- extensions.sqlite
│      │     ├──395,272 B (00.10%) -- cache-used
│      │     ├───52,880 B (00.01%) -- stmt-used
│      │     └────6,920 B (00.00%) -- schema-used
│      ├─────329,968 B (00.08%) -- addons.sqlite
│      │     ├──296,544 B (00.07%) -- cache-used
│      │     ├───29,152 B (00.01%) -- stmt-used
│      │     └────4,272 B (00.00%) -- schema-used
│      ├─────304,168 B (00.07%) -- webappsstore.sqlite
│      │     ├──244,080 B (00.06%) -- cache-used
│      │     ├───56,136 B (00.01%) -- stmt-used
│      │     └────3,952 B (00.00%) -- schema-used
│      ├─────257,544 B (00.06%) -- chromeappsstore.sqlite
│      │     ├──198,112 B (00.05%) -- cache-used
│      │     ├───55,480 B (00.01%) -- stmt-used
│      │     └────3,952 B (00.00%) -- schema-used
│      ├──────72,568 B (00.02%) -- other
│      ├──────35,120 B (00.01%) -- downloads.sqlite
│      │      ├──27,096 B (00.01%) -- cache-used
│      │      ├───6,024 B (00.00%) -- stmt-used
│      │      └───2,000 B (00.00%) -- schema-used
│      ├──────22,560 B (00.01%) -- content-prefs.sqlite
│      │      ├──12,032 B (00.00%) -- cache-used
│      │      ├───8,128 B (00.00%) -- stmt-used
│      │      └───2,400 B (00.00%) -- schema-used
│      ├──────13,232 B (00.00%) -- permissions.sqlite
│      │      ├───6,224 B (00.00%) -- cache-used
│      │      ├───5,744 B (00.00%) -- stmt-used
│      │      └───1,264 B (00.00%) -- schema-used
│      └───────6,936 B (00.00%) -- search.sqlite
│              ├──3,888 B (00.00%) -- cache-used
│              ├──1,840 B (00.00%) -- stmt-used
│              └──1,208 B (00.00%) -- schema-used
├────4,465,460 B (01.09%) -- images
│    ├──4,180,684 B (01.02%) -- content
│    │  ├──4,180,684 B (01.02%) -- used
│    │  │  ├──3,682,816 B (00.90%) -- uncompressed-heap
│    │  │  ├────497,868 B (00.12%) -- raw
│    │  │  └──────────0 B (00.00%) -- uncompressed-nonheap
│    │  └──────────0 B (00.00%) -- unused
│    │             ├──0 B (00.00%) -- raw
│    │             ├──0 B (00.00%) -- uncompressed-heap
│    │             └──0 B (00.00%) -- uncompressed-nonheap
│    └────284,776 B (00.07%) -- chrome
│         ├──284,776 B (00.07%) -- used
│         │  ├──284,776 B (00.07%) -- uncompressed-heap
│         │  ├────────0 B (00.00%) -- raw
│         │  └────────0 B (00.00%) -- uncompressed-nonheap
│         └────────0 B (00.00%) -- unused
│                  ├──0 B (00.00%) -- raw
│                  ├──0 B (00.00%) -- uncompressed-heap
│                  └──0 B (00.00%) -- uncompressed-nonheap
├────2,271,509 B (00.55%) -- layout
│    ├──1,151,453 B (00.28%) -- arenas
│    └──1,120,056 B (00.27%) -- styledata
├──────917,528 B (00.22%) -- xpti-working-set
├──────380,118 B (00.09%) -- dom
├──────191,658 B (00.05%) -- network-memory-cache
└────────5,312 B (00.00%) -- cycle-collector

Other Measurements
            0 B -- canvas-2d-pixel-bytes
    3,608,696 B -- gfx-d2d-surfacecache
   13,260,796 B -- gfx-d2d-surfacevram
    3,976,748 B -- gfx-surface-image
            0 B -- gfx-surface-win32
  391,700,304 B -- heap-allocated
  431,841,280 B -- heap-committed
    2,920,448 B -- heap-dirty
  112,663,902 B -- heap-unallocated
              2 -- js-compartments-system
             19 -- js-compartments-user
  100,663,296 B -- js-gc-heap
   16,652,264 B -- js-gc-heap-arena-unused
            0 B -- js-gc-heap-chunk-clean-unused
   39,605,888 B -- js-gc-heap-chunk-dirty-unused
         55.88% -- js-gc-heap-unused-fraction
  514,908,160 B -- private
  564,678,656 B -- resident
    1,052,672 B -- shmem-allocated
    1,052,672 B -- shmem-mapped
1,033,310,208 B -- vsize
Blocks: 484964
you have several problematic extensions installed that are known (atleast in my extensive testing) to cause firefox to not release memory

AVG Safe search
CoolPreviews (and CoolIris)
Firebug by design caches data when enabled (even if not being actively used)
I have the same problems that David.P does.  In my experience GC is a problem too, but there is no question that FF4 is far slower graphically (on my hardware) than FF3.6.  As soon as I tried FF4 for the first time I noticed it.

Like David, I find everything about the way pages are displayed slower (eg. scrolling).  For example, an easy way I found to compare performance is to go to http://www.mozilla.org/en-US/firefox/features/ and run my mouse back and forth between 'Desktop' and 'About' on the menu's at the top.  

In FF3.6 my CPU hovers 20-40%; all the menus dropdown on queue.  

In FF10 this PINS my CPU; the menus only dropdown if I keep my mouse hovering on one of the items for about half a second.

I've tested this on clean profiles, no extensions, one tab.  Disabling hardware acceleration in FF and in XP makes no difference.  I also tried disabling hyper-threading, write combining and gfx.canvas.azure.

Windows XP SP3
3.00 GHz Pentium 4
256MB NVIDIA GeForce 6200 (EVGA)
I should note the behavior reported in the previous comment 298 (and profiled here on Linux) is different than the title/initial message, which is *periodic* freezing, not general slowness or menu slowness.  This probably should be a separate report or tied to another bug.  

Menus were surprisingly slow (and a super-fast machine), clean profile.  I don't see a lot of CPU used inside FF (this was a normal jprof, not real-time), but I see a LOT of forks() and a surprising hit to nsSound::PlayEventSound()
Probably something to do with libcanberra trying to play a system menu sound --- bug 567746, or bug 110385, or a new bug. Please file if necessary.
In any case, my test isn't a good one for this report (I'm on Linux).  And this should be a separate bug report, since it's not periodic slowness.

However, if a ultra-fast Xeon running F15 can't smoothly strum menus, something is wrong.  (I suspect roc is correct here; it's both the fact that we play sounds on menus and that the infrastructure for playing them on Linux is blocking and involves a fork.)
Spun off the WinXP(?) graphical/menu regression reported in comment 298 as bug 716445, and the Linux sound/fork() performance issue as bug 716446.
(In reply to Martijn T. from comment #292)
> I've decided to upload my case since I'm one of the original reporters and
> although the problem has been absent on my Fx for a while, it seems it's
> popping up again.
> 
> This is on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101
> Firefox/8.0 on the release channel. 

> The document in about:memory that has almost 1/3rd of the allocated memory,
> is a surprisingly simple gdocs document with about 10 pages and nothing but
> text. No pictures, attachments, imports.

Martijn: you should file this as a separate bug as well - a 500MB compartment for a "simple" google doc certainly seems excessive to me, and the cause of that (or the existence of that with GC/CC) could be the cause of pauses you see.
I've seen some mention of the page file and would like to say that it's unrelated. I've had this problem since before this bug was opened and I've never used a page file.
running GC/CC across memory that has been paged out does incur latency penalties.

"I've never used a page file."

thats your own mistake.
(In reply to Randell Jesup [:jesup] from comment #303)
> Martijn: you should file this as a separate bug as well - a 500MB
> compartment for a "simple" google doc certainly seems excessive to me, and
> the cause of that (or the existence of that with GC/CC) could be the cause
> of pauses you see.
I have 'studied' the problem further, and then submitted this report: https://bugzilla.mozilla.org/show_bug.cgi?id=704894
The shorter pauses where just the start of that I think.

Meanwhile:
I have upgraded from 4 GB DDR2 to 8 GB of DDR3. It was needed for my work in Photoshop. The problems with Firefox stuttering seemed to have disappeared, completely, after that upgrade. The only change to the system was the memory, no other changes in hard- or software.

Of course this is not a very detailed report, but nevertheless I think that it is good to have it here for reference.
(In reply to Orhan "aib" Kavrakoglu from comment #304)
> I've seen some mention of the page file and would like to say that it's
> unrelated. I've had this problem since before this bug was opened and I've
> never used a page file.
If we are talking about a Windows page file - not having a page file in Windows could have big consequences for performance. Microsoft has several Knowledge Base articles on what the (minimum) size of the page file should be, and I would suggest it is best to stick with that.

It's not that I like having a page file, it's just that the impact of not having one in Windows is sometimes bigger than people think.
(In reply to Martijn T. from comment #307)
> If we are talking about a Windows page file - not having a page file in
> Windows could have big consequences for performance. Microsoft has several
> Knowledge Base articles on what the (minimum) size of the page file should
> be, and I would suggest it is best to stick with that.
> 
> It's not that I like having a page file, it's just that the impact of not
> having one in Windows is sometimes bigger than people think.

Oh I know all about the arguments for using a page file, trust me. My decision is informed. I'm in love with the impact of not having one in Windows :).

As for FF, I doubt that's the issue here.
I did an exhaustive run through of my add-ons after launching in Safe-Mode determined that it was an add-on based problem for me.

After disabling everything, it came to it that TorButton was the add-on that was causing the problem, so I'd say if you're running TorButton and launching firefox in safe-mode fixes the issue, start by disabling TorButton just to give it a shot.

GOOD LUCK! :D
> After disabling everything, it came to it that TorButton was the add-on that
> was causing the problem,

Thanks for the info!  That's very helpful.  Bug 719329 is now open to track this specific TorButton issue.
Bug 687709 sounds similar to this one, and I am certain I am experiencing that one.

If you think they are duplicate bugs, or even related, feel free to shout me if you want more info.
Saw this bug in Chromium, which although it is a different browser, appears to be a similar issue:
http://code.google.com/p/chromium/issues/detail?id=111514

It states at one point that it is a "4 way deadlock between the
browser->plugin->renderer->gpu"

Just in case.
FWIW, I've just upgraded from 3.6 to 10 at work (finally!) and if anything, 10 is worse. The periodic freezes in 3.6 wouldn't become too bothersome until later in the day, but in 10 I'm seeing significant pauses much earlier. The pauses are shorter, but much more frequent and seemingly random, as much as every two seconds, to long spacings where I can type and see letters appear on the screen at the same time as I press keys, for a whole sentence or two.

I'm thinking that despite the elation of fianlly getting our customer database to be Firefox 4+ compatible and finally being able to upgrade, I may have to return to 3.6 as ultimately it performed *better*.

The I/O spikes (session saver I presume) shown in Process Explorer are still regular, but the CPU and memory spikes are all over the place and are no longer regular as they were in 3.6.

Maybe it's still Html Validator or Firebug/Eventbug leaking memory, although those too have been upgraded in accordance with the new Firefox version.

Sad.
It would be great if you could install this:
https://addons.mozilla.org/en-US/firefox/addon/aboutjank/
and visit about:jank after a hang. The resulting data would probably be very helpful to figure out what's going on.

Also, some major fixes have gone into the latest builds. Try a Nightly and see if things have improved.
I have had 'more frequent and seemingly random' pauses a few weeks ago, but that was ONLY when I had the Firebug plugin installed. It didn't need to be active or anything. It made Fx behave very sluggish in almost anything.

It was gone after removing Firebug. I guess it's easy for you to test wether Firebug is the problem here or not. Installing and removing is just a few clicks and to my opinion, definitely worth testing.

Also, I believe Firebug is pretty notorious for this problem, even on Chrome. That's the whole reason Firebug Lite is there. Although a recent changelog now lists: "Firebug doesn’t slow down Firefox start time anymore since its loaded as soon as the user actually needs it." This was before I experienced my sluggishness.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #314)
> It would be great if you could install this:
> https://addons.mozilla.org/en-US/firefox/addon/aboutjank/

"Not available for Firefox 10.0" ???

(In reply to Martijn T. from comment #315)
> It was gone after removing Firebug. I guess it's easy for you to test wether
> Firebug is the problem here or not. Installing and removing is just a few
> clicks and to my opinion, definitely worth testing.

Firebug is famous and widely used, and pretty much an essential tool! Uninstalling Firebug is completely unacceptable. I wish I could use it more often, but I limit myself to how often I dare invoke it, and I have not installed it at home out of sheer fear of performance problems. I would so dearly love to be able to have it available at all times even at home.

If it really is Firebug then someone needs to bang Mozilla and the Firebug teams' heads together and work out what's going so tremendously wrong that Firebug can grind Firefox down without even opening the Firebug panel! (One reason for wanting to upgrade from FF 3 to FF 4+ was to see if fixed all the dreadful bugs in Firebug ... I've wasted hours over Firebug being more broken than the code I'm trying to debug, such as watching it step into code that doesn't get executed and believing that it does.)

I don't really want to use a nightly on my work PC all day -- I need something reliable. I could wait for 11, but we've gone 3-4-5-6-7-8-9-10 and still not managed to bring the garbage collector under control, if that's what it is.
(In reply to Daniel Beardsmore from comment #316)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment
> #314)
> > It would be great if you could install this:
> > https://addons.mozilla.org/en-US/firefox/addon/aboutjank/
> 
> "Not available for Firefox 10.0" ???
Yes, this add-on requires latest aurora or nightly
This issue is not related to Firebug as I had never installed Firebug, but I have had the same serious performance/freezing problems with FF v3.6 through v11 (on all of my different machines) for like years. See e.g. my comment #280 (and many more in this thread).
(In reply to Daniel Beardsmore from comment #316)
> I don't really want to use a nightly on my work PC all day -- I need
> something reliable. I could wait for 11, but we've gone 3-4-5-6-7-8-9-10 and
> still not managed to bring the garbage collector under control, if that's
> what it is.

Aurora and Nightly are actually pretty stable.  You can install either of them alongside the release version, and use the same profile and everything, and switch back and forth as needed (though you can't run both versions at the same time with the same profile).
(In reply to David.P from comment #318)
> This issue is not related to Firebug as I had never installed Firebug, but I
> have had the same serious performance/freezing problems with FF v3.6 through
> v11 (on all of my different machines) for like years. See e.g. my comment
> #280 (and many more in this thread).
You need no introduction. I've been CC'ed this bug for more than more than two years.

Why are you referring to "This issue" here? The issue Daniel is describing is completely different from the issue that is described when this bugreport was started. Daniels pauses are 'more frequent and seemingly random sluggishness' while this bugreport is about periodic, non-random pauses.

Please stop making every type of pause you spot a part of this bug. If the pauses you experience are completely random, than it's not this bug: create a new report.

Daniel:
(In reply to Daniel Beardsmore from comment #316)
> Uninstalling Firebug is completely unacceptable.
I'm not suggestion you uninstall it forever. I suggest you test wether Firebug is the issue. If it is: report it to the Firebug developers. If it isn't: it may be a different plug-in, it may be Firefox, but your issues are different from the problem we're tracking in this bug report to my experience. For proper tracking you should issue a seperate report to my opinion.

> If it really is Firebug then someone needs to bang Mozilla and the Firebug
[...]
> reason for wanting to upgrade from FF 3 to FF 4+ was to see if fixed all the
> dreadful bugs in Firebug ... I've wasted hours over Firebug being more
> broken than the code I'm trying to debug, such as watching it step into code
> that doesn't get executed and believing that it does.)
What you are saying is that Firebug is famous, widely, perhaps essential for some, but moreover: a product in development (or a **** piece of software if it's a final product) - that doesn't need to have anything to do with Firefox. 

They're not here to clean up the mess Firebug hasn't handled (yet). Firebug is a plug-in that is searching the borders of plug-in possibilities on Firefox to my view. Firebug is purposely attempting to get the maximum out of Firefox; but it's their choice and their choice alone to offer a buggy product to you.
> Why are you referring to "This issue" here? The issue Daniel is describing
> is completely different from the issue that is described when this bugreport
> was started. Daniels pauses are 'more frequent and seemingly random
> sluggishness' while this bugreport is about periodic, non-random pauses.

3.6 to 10 is a large leap (I still have 9 at home and 10 may have changed this somewhere). I strongly suspect that this is the same problem and that the garbage collector changes have ended up randomising the freezes somewhat. They're not truly random, it seems that there's a pattern. At a guess, the program is trying to even out the load, but the load is just too much. Possibly the interruptible garbage collector is running its process in brief steps, leading to a short pause every couple of seconds until it's done, then I get a period of decent responsiveness for a while until it has work to do again. It's not the session saver as that's generating the predictable I/O traces.

I have Process Explorer's CPU graph running in the tray, and I can see at a glance when Firefox is genuinely tied up (4-10 have some performance issues with Flash and animated GIFs) and this is Firefox just continually needing to pause briefly to do something for no clear reason, with the same little CPU and RAM spikes, just not consistent as they were in 3.6.

The reason heads need banging together is that party A will always say "not my fault" and blame B, and B will say the same of A. Firefox can't be at fault, must be Firebug. Firebug can't be at fault, must be Firefox. It's definitely not Firebug's fault (I still get the same periodic freezes in FF 9 without Firebug, but FF 4+ takes a lot longer than 3.6 before it starts to become a real issue), yet Firebug in my experience is the most likely to disturb Firefox and slow it. That's where you're most likely to be able to observe the interaction and co-operation in analysis could help.

Now, I understand that the nightlies have more fixes, and I'm almost happy to wait a bit longer, but this is dragging on ...
(In reply to Daniel Beardsmore from comment #321)
> Now, I understand that the nightlies have more fixes, and I'm almost happy
> to wait a bit longer, but this is dragging on ...

Dragging on, yes. But with telemetry and the Snappy projects, the search now has more direction :) Not to mention that if these are architectural problems with the current GC (i.e. your usage pattern will always lead to a slow browser, even with everything working properly), well.. incremental GC and generational GC are actively being worked on now and should come in a few more revisions.
(In reply to Martijn T. from comment #320)

> You need no introduction. I've been CC'ed this bug for more than more than
> two years.

I believe that there was no mention of introducing anyone especially to _you_, of all things...

> Please stop making every type of pause you spot a part of this bug. If the
> pauses you experience are completely random, than it's not this bug: create
> a new report.

You should tell this to the participants who HAVE made 'random' pauses "a part of this bug", in contrast to 'regular' freezes (which I have not). At any rate, Daniel has cleared this up in the meantime, anyway.
I don't want to go back to 3.6 – I much prefer 4+. If I'm about to go postal from the constant pauses, I'll try disabling Firebug. I don't strictly need it on my desktop PC as I can run tests from my laptop instead, and put Firebug on there. A nuisance, but a stopgap so long as I don't have to wait until Firefox 27 for the speed to pick up ;-)
In Firebug case I suggest you completely uninstall it, I saw profiles where just disabling it doesn't help
Did anyone find a rational explanation why code that isn't running, is running ...?

That sounds like a pretty drastic bug in its own right ...
Don't have enough time to proper investigate and report...
> Uninstalling Firebug is completely unacceptable.

He's not asking you to get rid of it forever, just to uninstall it, repeat the test and install it back.

Surely you can do it if it helps diagnose the problem.
(In reply to Alex from comment #328)
> > Uninstalling Firebug is completely unacceptable.
> 
> He's not asking you to get rid of it forever, just to uninstall it, repeat
> the test and install it back.

Not if it's breaking Firefox and I need to use Firebug every day! However, I'll probably move it to my laptop ...

(I'm more disturbed that add-ons can cripple a browser when disabled -- that's going to be having a serious effect on testing and debugging if that's the case. I know so little about add-ons that I can't tell whether it's even feasible or not -- I thought that with disabled add-ons, everything Firefox knows, it pulls from the RDF, and nothing is ever executed? I'm very sceptical myself. Obviously in my case I would start out by disabling Firebug!)
(In reply to Daniel Beardsmore from comment #313)
> FWIW, I've just upgraded from 3.6 to 10 at work (finally!) and if anything,
> 10 is worse. The periodic freezes in 3.6 wouldn't become too bothersome
> until later in the day, but in 10 I'm seeing significant pauses much
> earlier. The pauses are shorter, but much more frequent and seemingly
> random, as much as every two seconds, to long spacings where I can type and
> see letters appear on the screen at the same time as I press keys, for a
> whole sentence or two.

> The I/O spikes (session saver I presume) shown in Process Explorer are still
> regular, but the CPU and memory spikes are all over the place and are no
> longer regular as they were in 3.6.

Note that the sessionstore.js pauses (tracked in a different bug) would be similar to your reports, and are written asynchronously (but are collected and generated synchronously, which causes the pauses).  Also, if you're using IO spikes from the OS, I'd be cautious as OS's can often hide or merge or delay actual IOs from hitting disks.  So I wouldn't completely discount sessionstore as a cause.  How large is the file (in your profile dir)?  How many tabs do you have open (roughly)?

> Maybe it's still Html Validator or Firebug/Eventbug leaking memory, although
> those too have been upgraded in accordance with the new Firefox version.

The primary test is easy - Help->Restart with Add-ons disabled, and see if the problem is still there.
If you're paranoid about Firebug, delete the extension before rebooting; you can always re-install it.  And I *think* there's now a no-restart, lazy-loading  Firebug release, so that should minimize any impacts.

I'll put $5 on the Add-ons being the primary culprit :-)
I've disabled a few add-ons that I either don't need, or that analyse every page load (Firebug, EventBug, Html Validator, JSView and Restart Firefox) and the program is now significantly faster in general (at least one of those slows the program down a great deal). Stylish is the other add-on that gets heavily involved with page content, but I've left that running for now as it's useful for certain things, such as providing a fake focus ring for certain buttons ;-) (I need to figure out how to get the real one back, ugh)

It remains to be seen how performance pans out, and I don't leave my work PC logged in for months at a time like I do at home -- Firefox at home  tends slow down over a period of a few days. I've turned off JSView at home though, as I don't actually use it enough to be worth keeping it.
Right, well, performance is now stellar. At some point I need to start enabling add-ons one by one and see where things start falling over ... The lack of Firebug isn't as bad as the web developer built-ins help, although some refinement is needed!

Either Firebug is not the cause, or disabling it works perfectly.
Well the consistent behavior is that when Commit exceeds private bytes/working set the browser becomes far choppier and far likely to become unresponsive for periods of time.

One suggestion is getting more ram, 
another is making use of the windows api to make firefox do its best to keep its entire working set in physical memory when you swap back to it.
(In reply to Danial Horton from comment #333)
> Well the consistent behavior is that when Commit exceeds private
> bytes/working set the browser becomes far choppier and far likely to become
> unresponsive for periods of time.

The only commit I know of is the total amount of memory space Windows is using (relative to the page file, not physical RAM), and private bytes is process specific. Therefore, commit charge will always under all circumstances exceed the private bytes for any one process. What circumstances are you thinking of here?

> One suggestion is getting more ram,

I'm not sure whether you're suggesting that I'm actually running under RAM deficit, or that I need to increase the amount of free RAM on the computer. I've got 2 GB, typical usage is 1.0 GB physical in use, with a 1.2 GB commit. It's not like I'm skirting or exceeding my physical memory.

After I upgraded from 3 to 10, at the end of the day Firefox was using 1 GB instead of 300-500 MB, so something was leaking massive amounts of memory there. I'm guessing that the problem was the garbage collector struggling with this load. It's not a fair test as upgrading FF from 3 to 10 afforded upgrades to HTML Validator, Firebug etc so maybe one of those developers put out a shockingly bad release that leaks even more than it normally does ...
"Therefore, commit charge will always under all circumstances exceed the private bytes for any one process. What circumstances are you thinking of here?"


Take note that i mentioned the working set as well as private bytes.

The working set is always higher than commit charge for a process until a memory pressure event occurs in the windows memory management.  Once the commit charge exceeds the working set, collectors suffer penalties and you start to notice lag switching tabs and pauses when opening new ones.

Part of the problem i have observed is that GC is performed across paged out data incurring latency penalties (Filemon with the swap file filtered then spam the GC button a few times and you'll see a bunch of read/writes) Theres no doubt the completion of a generational GC would highly reduce the amount of lags incurred in this case alone.
It all depends whose tools you use. There's no such thing as "private bytes" in Task Manager in 7. However, there's no such thing as per-process commit in Process Explorer, which I use in XP (and Task Manager won't even start as I've replaced it with procexp). Task Manager's terminology changed between XP and 7 and I think private bytes in XP became private working set in 7. (Granted, I'm a version of procexp behind as I hate the new solid grey graphs they introduced.)

Since no-one wants to document any of these terms, or come up with anything resembling standard terminology, it's hard to be sure what anyone means unless they stick to the terminology of a single tool, and nothing you've said matches anything I've got installed.
Also, in Win 7, Task Manager, comparing Working Set (Memory), Memory (Private Working Set) and Commit Size, Commit Size is always larger than Memory (Private Working Set), and there's no pattern as to whether Commit Size or Working Set (Memory) is larger, even within processes of the same program. There's no memory pressure as, of the 1 GB physical RAM, systemwide usage is 557 MB commit and 363 MB physical.
IE1(In reply to Danial Horton from comment #258)
> the AMD 3500 is NOT a p4 equivalent.
> also iirc the x800 does not gain hardware acceleration either as it lacks
> the necessary texture resolution support.

What are you talking about. I am running Windows 8 on a very old Radeon X300 card and a 3GHz P4.

IE10 has full hardware acceleration by default (the option isn't greyed out in settings). Its performance is fantastic and CPU usage never goes over ~60% when performing all sorts of tasks, while having HWA enabled. When HWA is disabled, IE10 it performs much worse.

Chrome also has HWA (after manually enabling it). However it does have very minor visual glitches but they're hardly noticeable. Performance is slightly worse than IE10.

Firefox has no hardware acceleration whatsoever even when forced by changing Direct2D and layers settings (it just crashes on startup). CPU usage is constantly at >65% (even with a clean profile) when performing slightly complex tasks, even scrolling shoots it right up to like 90%.

The facebook photo viewer/theatre also has this irritating kind of double refresh on the photo its loading. It takes like 10 seconds to load a photo properly in the viewer, which is why I always just choose to just open the photos in a new tab to avoid this. IE10 doesn't have this problem.
I've seen others even with decent computers with full HWA in Firefox have this problem.

dxdiag shows that DirectDraw, Direct3D and AGP Texture Acceleration are ENABLED.

Even after this I still prefer Firefox because of its customisability.
(In reply to ... from comment #338)
> IE1(In reply to Danial Horton from comment #258)
> > the AMD 3500 is NOT a p4 equivalent.
> > also iirc the x800 does not gain hardware acceleration either as it lacks
> > the necessary texture resolution support.
> 
> What are you talking about. I am running Windows 8 on a very old Radeon X300
> card and a 3GHz P4.
> 

the Netburst Pentium 4 is INFERIOR to the Pentium M and AMD K8 architectures

> IE10 has full hardware acceleration by default (the option isn't greyed out
> in settings). Its performance is fantastic and CPU usage never goes over
> ~60% when performing all sorts of tasks, while having HWA enabled. When HWA
> is disabled, IE10 it performs much worse.
> 

the x300 does not support 4k texture resolutions. This is a requirement for the accelerated backend that Firefox uses. 

IE only applies acceleration on content, of which i believe the backend breaks parts of the screen into 2k^ slices

> Chrome also has HWA (after manually enabling it). However it does have very
> minor visual glitches but they're hardly noticeable. Performance is slightly
> worse than IE10.
> 
Of course, since your hardware doesn't support the required texture dimensions there will be issues

> Firefox has no hardware acceleration whatsoever even when forced by changing
> Direct2D and layers settings (it just crashes on startup). CPU usage is
> constantly at >65% (even with a clean profile) when performing slightly
> complex tasks, even scrolling shoots it right up to like 90%.
> 

As mentioned before, thats through thte lack of 4k^ textures, AMD did not add these till R500 based processors

> The facebook photo viewer/theatre also has this irritating kind of double
> refresh on the photo its loading. It takes like 10 seconds to load a photo
> properly in the viewer, which is why I always just choose to just open the
> photos in a new tab to avoid this. IE10 doesn't have this problem.
> I've seen others even with decent computers with full HWA in Firefox have
> this problem.
> 
> dxdiag shows that DirectDraw, Direct3D and AGP Texture Acceleration are
> ENABLED.
> 
> Even after this I still prefer Firefox because of its customisability.

I do believe Bas knows of that issue and was looking to resolve it in azure?
This problem has been happening to me since Firefox 4. Firefox completely stops responding every 10 mins or so for about 30 seconds to a minute.  Flash videos stop playing and all input is unresponsive until Firefox wakes up again.  

I traced this problem down to it updating the feeds for my RSS subscriptions in my bookmarks (I had 3 or 4 RSS subscription bookmarks). Once I removed the bookmarked RSS feed subscriptions the pauses have gone. BTW: I was experiencing this problem on Windows XP/Windows 7 and Linux.
As #39 pointed out... developers are ignoring this (For whatever reason).... my suggestion is everyone delete and discard Firefox until they feel it's a bug worth fixing... My original post/complaint has found many responses except from mozilla...
TOO BAD....  i LIKED FIREFOX UNTIL NOW....My laymans opinion is Mozilla has become the DATA MINER that microsoft became a long time ago.... and their priorities have abandoned that of their users
We've actually helped a number of commenters here find the root cause of their problems - and most of them have been not core Mozilla code.  Fore example Daniel Beardsmore found it was addons - after disabling a number: "Right, well, performance is now stellar."

The most recent report (David Roberts) appears to have tracked down a cause - a bug needs to be filed on that cause, not a comment here in a long, generic/fuzzy bug which long ago lost a specific focus and became kindof a meta bug.   That's great, because (if it gets filed), we have a good chance of fixing it (if it hasn't been fixed already; we've had a serious push on responsiveness issues like this for the last year (the Snappy project).  One clear cause to some people's problems was bug 669034 (sessionstore-induced pauses); lots of work has been done on that and more is still ongoing.

If you have specific problems, please file a new bug; this one really is no longer "a bug report".
Excuse me a moment while I don my flame-proof pants... ok, done.

I suggest we declare bankruptcy in this bug and close it.  I don't suggest this because Mozilla doesn't care about pauses -- on the contrary, there's a high-priority project (https://wiki.mozilla.org/Performance/Snappy) devoted entirely to reducing pauses.

Rather, I suggest it because this bug in its current form is unlikely to lead to any useful outcomes.  More specifically (a) it describes extremely vague symptoms, and (b) has had dozens of people pile on, saying "me too".  The problem is that it's very likely that there are dozens of distinct problems that are causing the pauses seen by all these people.

Bug reporting works when a single bug report describes a single problem that requires a single fix.  This bug does not match that description.  For those people who are still seeing pauses, I request you each file a new bug;  feel free to link to it from here.  In your bug, please put as much detail as possible.  For example... Do the pauses happen on a particular website?  Do they happen with recent versions of Firefox?  Do they only start to happen after Firefox has been running for a while?  If you do that, the chances that somebody will be able to fix your problem are *much* higher than if you are relying on this bug.

TL;DR:  Mozilla cares greatly about reducing pauses, but this bug is not helping anyone achieve that.  Let's file new bugs and close this one.
I complete agree with Randell and Nicholas.
Agreed. Every symptom I personally reported here is no longer present in v12 - good work on that. *There are new ones*, no denying that, but I see little point discussing them here, since they are completely different.

See also:

bug 646941 - this got fixed (through work done on other bugs)
bug 704894 - new one I'm still experiencing
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Sure ... makes sense. I'll file a new bug report.  My symptoms match the very first post pretty closely (Regularly freezing for a few seconds every few minutes) so hence my comments in this thread.
Whiteboard: READ COMMENT 39 BEFORE COMMENTING → please read comment 343 and file a new bug for your issues
Depends on: 763868
The problem is back, and it's worse than I've ever seen it before.

FF is completely unresponsive/blocked/stalled for several seconds about once every minute.

Firefox v.13.01 on Win7.64bit
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #348)
> Do you feel up to getting information from the profiler?
> https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-
> in_Profiler

And if you do, *please* present anything you find in a new bug, as per comment 343.
(In reply to David.P from comment #347)
> The problem is back, and it's worse than I've ever seen it before.
> 
> FF is completely unresponsive/blocked/stalled for several seconds about once
> every minute.
> 
> Firefox v.13.01 on Win7.64bit

For once-every-minute stalls, I've most often found they're due to some tab/website doing something stupid (like the twitter feed in Huffington Post pages storing huge amounts of data in a DOM tree, or tbpl storing thousands of changesets if you don't reload the page, etc).  Few tings within the browser happen every minute; that's not an uncommon time period for web pages to do stuff.  

See if you can divide-and-conquer on your tabs to see which one (if any) is causing the problem.  Also, about:memory can sometimes point you at possible offending sites.
Actually, it's not once in a minute -- more like every 20 seconds -- but not in regular intervals.

This really starts to **** me off. 
(Btw., and this even more:
https://blog.lizardwrangler.com/2012/07/06/thunderbird-stability-and-community-innovation/comment-page-7/#comment-39115)

Honestly, I'm only still using Mozilla products (in the office, that is) because of some Add-Ons that I have come to rely on for my professional work. EVERY other computer where I get my hands on gets Opera installed. Opera just works, and feels about five times as crisp and responsive. Sorry guys.

Apart from that: will I have to use Nightly if I try this FF Profiler thing?
Firefox without addons is also crisp, responsive and very fast. Shame about its approach to addons, which has historically been to give them free rein and hope they don't mess everything up.

It's time to move on to severely limiting what you let third parties do to your browser/OS (and it seems browser/OS developers are generally warming to the idea) but easier said than done, especially for a large pre-existing product.
(In reply to Roman from comment #352)

All true except this part, unfortunately:
> Firefox without addons is also crisp, responsive and very fast.

Firefox (since v3.6 -- before that it WAS blazing) simply is UNUSABLE on a Netbook or other weaker hardware -- even in its virgin state without one single Add-On.

That's IMHO, of course. And relative to Opera, of course.

Other than that, I can see the problem that you are describing.

Hope to come back on topic,
David.P
David.P:  Please file a new bug.  Please.  We've trampled on this bug's grave enough already.
I will if somebody tells me if

> [...] I have to use Nightly if I try this FF Profiler thing?
(In reply to David.P from comment #355)
> > [...] I have to use Nightly if I try this FF Profiler thing?

Yes, you do. Thanks.
OK, Nightly is a little better, but also stalls regularly and completely (with longer intervals).

In exchange, the Profiler
http://666kb.com/i/c5gzb6u2egrgd0dxv.png

...doesn't work.

When I click on "Analyze", It just sits there empty and forever like this:
http://666kb.com/i/c5gytaakyxzzrc0b7.png
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #358)
> Benoit, see comment #357.

That's caused by bug 773507. We have worked around the issue in 'Gecko Profiler 1.8.3' or later.
Now that the Profiler works:
http://666kb.com/i/c5n806wnolf63enx9.png

...what do I do to find out what is still causing Firefox to hang every couple of minutes for like two seconds?
That stack doesn't look right. I think we'll need more help from Benoit.

Also, I think about:jank might be helpful here. See https://developer.mozilla.org/en/Debugging/Existing_Tools.
If there's a tab that does stuff every couple of minutes, that can cause this if the tab accumulates data and gets slower.  For example, a tbpl tab left open too long (a week) can drag a high-end PC to it's knees, because the amount of data being processed and reflowed becomes immense.  This isn't a bug in Firefox, it's a bug in the page.

This type of scenario would be easier to diagnose if there was some way to associate delays with the tab that causes them.
(In reply to David.P from comment #360)
> Now that the Profiler works:
> http://666kb.com/i/c5n806wnolf63enx9.png
> 
> ...what do I do to find out what is still causing Firefox to hang every
> couple of minutes for like two seconds?

Yes, the profiler is not working as intended but I have no idea what is happening. Can you try again by first stopping the profiler, unchecking 'Stackwalk', restarting the profiler?
'Stackwalk' was not even checked from the very start.
Updated Nightly, now the Profiler looks better. Will report back.
Cool, make sure you're running nightly from 07-19 and Gecko Profiler 1.8.4. All these changes are very new so you'll need the latest version for it to work properly.
Is this of any use?
http://people.mozilla.com/~bgirard/cleopatra/?report=de7deace26a9a0886e2c6849f6ca0119fe48ef94

It's been made instantly after Nightly hung for two seconds.
Unfortunately, profiling directly after a hang is less effective than a profile that includes the hang. However, I notice code running in that profile that can be traced to both LiveClick and LastPass; you may want to try disabling those two addons and seeing if the hangs persist.
(In reply to David.P from comment #367)
> Is this of any use?
> http://people.mozilla.com/~bgirard/cleopatra/
> ?report=de7deace26a9a0886e2c6849f6ca0119fe48ef94
> 
> It's been made instantly after Nightly hung for two seconds.

Yes it is. You're problem is LiveClick with nearly 100% certitude. I suggest to disable the addon. I can tell in your case your browser froze for 6 seconds because of LiveClick which is insane!

(In reply to Josh Matthews [:jdm] from comment #368)
> Unfortunately, profiling directly after a hang is less effective than a
> profile that includes the hang.

The hang was very long, but it's possible to catch them completly (but often the tail is sufficient) by increasing the buffers size and/or decreasing the sampling rate.
liveclick is doing a bunch of sql stuff, which is the cause of your hangs, as best I can tell from the profile.  Disable it and report it to the author.

Makes me wish we had a better way to tag extensions with known issues...
Benoit: sure enough that diagnosis was spot-on, and there is no hangs whatsoever after having removed LiveCLick :-O

This new Profiler honestly seems to be the greatest (most effective) thing from Mozilla since sliced bread.
David.P:  I'm glad the profiler found that LiveClick is the problem.

Now, can we please all heed comment 343 and report any new issues in a new bug report?  Thanks.
Whiteboard: please read comment 343 and file a new bug for your issues → NO MORE COMMENTS PLEASE! -- please read comment 343 and file a new bug for any issues
this is back with a vengance for me in firefox 22, I filed a new bug report.

when I enabled javascript mem logging it shows cc run every second and gc about 2-3 seconds.  This is with the browser idle its just looping CC and GC, and GC taking over 400ms.
blocking-b2g: --- → madai?
(In reply to Josh Matthews [:jdm] from comment #368)
Flags: needinfo?(nobody)
blocking-b2g: madai? → ---
Flags: needinfo?(nobody)
You need to log in before you can comment on or make changes to this bug.