(No comment was entered for this change.)

This is more of a meta bug or a duplicate bug.  There are several things at play here, 
and many related bug reports.

Well what's the duplicate then? Either this bug should be targeted at a milestone
with someone to investigate, or the duplicate found, added to the Jank label,
targeted and assigned.

(No comment was entered for this change.)

The "tabs gets detached" bug happened more frequently to users with "old" tabs

 Issue 2105  is probably the most popular issue about this
some info in http://code.google.com/p/chromium/issues/detail?id=8628#c2 too

also  Issue 17178  and Issue 18753

To be clear, this bug is about the problems caused when the renderer is swapped out 
and takes a while to swap in.  There are several potential not-mutually-exclusive 
solutions:

* Reduce the renderer memory footprint, e.g. by kicking caches out of memory on 
idle or after some time threshold, by having V8 garbage collect and compact, etc.

* Do tricks to hide the renderer swapping back in, such as backing the backing store 
with a file that we can quickly read of disk in one go and at least make a static image 
of the page come up quickly while the renderer tries to swap in

* Play tricks with keepalive pings, OS hints etc. to try and shape what gets swapped 
out

More?

cpu, if you are not looking into this, please unassign yourself.

 Issue 2105  has been merged into this issue.

One other ntoe: The possible cause of  issue 2105  is the _backing store_ getting swapped 
out.  We never want to swap the backing store back in from disk.  My rough memory of 
Darin's recent comments on this is that there may be some way to keep the backing 
stores on the GPU instead of in main memory, which would mean that the GPU would throw 
them away (?) instead of swapping to disk.

Another note: when the system is under major memory pressure, the renderers should 
really clamp down into utter minimization mode -- not just throw out caches, but 
serialize their state off to disk and kick themselves out of memory, or something.

 Issue 11063  has been merged into this issue.

 Issue 21230  has been merged into this issue.

Carlos: are you actively looking at this?

(No comment was entered for this change.)

(No comment was entered for this change.)

After weeks waiting to patch I am back on Firefox, bye chrome!

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Most certainly our excessive use of memory and poor memory page management in tcmalloc 
is hurting us here big time.

not sure if this info will help or not...  but I just noticed the SAME type of
problem today while viewing a webpage that uses Silverlight, using IE8.  Strange...

In Mac Chromium, I don't experience a lockup of the computer or browser, only the 
symptom that clicking on a tab that hasn't been used recently will give me a blank 
tab for a few seconds. I can switch tabs without an issue even if the first tab has not 
finished re-rendering yet.

Is the lockup and the extremely slow line-by-line redraw still happening on other 
platforms?

I'm on nightly r27530.

> Is the lockup and the extremely slow line-by-line redraw still happening on other 
platforms?

Line-by-line redraw is still the case on Windows with Beta channel, when many tabs are 
open (which don't fit into physical RAM?)--until redraw is complete, the whole system 
is unresponsive.

@22 and @23. Yes, the memory has been paged out to disk and the redraw is touching 
every page causing a page fault that reads the page from disk, this can make the 
computer very slow.

I believe this can happen in any OS.

What @22 is observing is the "backingstore lost" effect, Meaning that we only have a 
few backingstores (5) and the different tabs compete for them. At some point some tab 
is going to loose its backingstore and upon that tab being made visible it will regain 
an empty backingstore and force a full redraw.

This may be hugely aggravated by bug 25336.

How much more are we going to do here for M4?  Should this bug block M4?

(No comment was entered for this change.)

 Issue 17178  has been merged into this issue.

There are a number of reports that the worst problems here come when waking up from 
hibernate, not just sleep.  I don't think anyone on the team knows precisely how 
hibernation affects memory pages.

 Issue 25152  has been merged into this issue.

Replacing labels:
   Area-BrowserBackend by Area-Internals

Apparently hibernate writes the volatile memory to disk, pages presumably left where
they were previously unless the implementation isn't how I think it is.

 Issue 9979  has been merged into this issue.

(No comment was entered for this change.)

you should also merge  issue 8628  into this one, since there are many disgruntled 
comments there, with users thinking no action has been taken since 2008...

 Issue 8628  has been merged into this issue.

I am tapped in the short term. Releasing this bug.

I don't use sleep or hibernate mode, and I get this problem all the time, beta channel. Any progress at all on this issue?

(No comment was entered for this change.)

Still happening for me with Chrome 6.0.472.63, Win XP SP3, 2GB RAM, no other apps open, only two Chrome tabs open. Come back in the morning, line-by-line redraw which locks Chrome for about 60 seconds.

Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting

Does this meta bug have any utility anymore?  Can we close it?

I haven't seen this problem for some time, it only used to happen on my work PC with Intel onboard video.

This still happens in 7.0.517.44

Using Intel Core 2 Duo and 4GB of Ram. 

Comment 40 is from Oct 06, and  Issue 2105 , which is marked as a duplicate of this, has had people complaining about it within the last couple of weeks.

Are we sure that fixing the other blocking bugs will resolve this issue?

This meta bug seems to have some value in tracking the progress of the other issues.

laforge@chromium.org writes: "Does this meta bug have any utility anymore?  Can we close it?"

If anyone closes this bug (meta or otherwise), it should not end the generation of progress reports to those of us tracking (and still experiencing) the bug. Not that we enjoy the sporadic confirmation (which has astonishingly lasted *years* and spanned the entire lifetime of the product) that this is *not fixed*, but it would be distinctly worse to receive a final notification that the (*did I mention that it's not fixed?*) bug is "closed," never to hear another peep about the issue.

I have no idea what a meta bug is, nor do I have any idea what options this tracking system provides to those of us receiving notifications when a bug is closed, marked as a duplicate, or otherwise "resolved." Regardless, don't do anything that will prevent those of us following the bug to continue to receive progress reports until this bug is truly fixed (which it's not, in case you didn't know).

(No comment was entered for this change.)

Issue #21926 may be related: 'Ensure backing stores aren't swapped out.'

is there open bug for this?  (I didn't find one)
Or a closed bug?

comment 20:
> Most certainly our excessive use of memory and poor memory page management in tcmalloc is hurting us here big time.

Open lots of tabs in multiple windows, including plugins (e.g. youtube, 
hulu etc). Use computer for a while. Sleep it, wake it up, etc etc.

After hours and hours tab switching becomes unbearably slow. This is 
frustrating when you are trying to close tabs and the system must page them 
in in order to shut them down.

Honestly, it would be faster for me to shoot them and reload the page than 
wait for it to come back.

Sometimes when the tab is repainting the whole browser UI locks too, and 
the tab content is painted in a series of horizontal strips.

I would say this is one of the biggest obstacles using Chrome on my 2.4GHz 
dual core laptop/2GB RAM.

Assigning to Darin so he can find the right person to work on this :-)

Just reiterating that this bug still exists in Chrome 10.0.648.204

I was on firefox 4 for a month with no issues and switched back to Chrome when V10 was released. Speed was the marketing buzz for V10 but with this annoying bug speed really does not matter.

The problem is maybe even worse than described in comment #52, as in my experience Chrome now changes with a matter of several new tabs open from "it works pretty fast most of the time" to "it freezes the system completely, and you need to hard restart the whole OS just to start closing the extra tabs Chrome failed to handle" - there is even no warning that Chrome is close to making the system unstable - not to say it fails to completely prevent the system to going to such instability whatever a user does.

And Wontfixing the  issue 66827  addressing exactly that problem even without giving an effort to reproduce it is just no comments. 

I'm not sure if it's related.
But on Mac, with Chrome 12.0.742.53 beta
All tabs are frozen when till another form on other tab is submitted.

One of the possible ways to go: issue 90593: "Save never-used tab's page contents when Chrome starts using too much physical memory"

Comment 56 is not related to this bug.  You should probably file a separate bug.

You are right, in fact after writing this, I realized it could be about frequency change, did some experiments, and confirmed it. I was going to remove the comment, I'll do it right away.
Sorry for the noise interference.

(No comment was entered for this change.)

Could issue 104421 be related?