402768 - After crashing, it takes too long to restart Firefox (with hundreds of tabs to restore)

Status: VERIFIED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071104 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071104 Firefox/2.0.0.9

After faulting, even after *three* years of a reported bug, #263160 which is well documented and should have been cleared by now -- Firefox fails to star restore itself in a reasonable fashion.  With 41 windows & 338 tabs it takes over 15 minutes of CPU time on a Pentium IV to restore itself.  I watched the CPU usage during the time frame.  The network usage was busy for a period (perhaps 2/3 of the time), but the CPU usage was busy for a much longer period.

Reproducible: Always

Steps to Reproduce:
1. Crash a Firefox session due to excessive CPU use.
2. Attempt to restore that Firefox session.
Actual Results:  
Firefox takes excessively long times when reinvoked to return to a functional state if the load prior to its crashing was "heavy".

Expected Results:  
There is no reason why Firefox should not return to a functional state immediately after its re-invocation.  All restoration of "previous state" information should be conducted in background mode.

Make a stronger effort to break it and stress test it before releasing it.

I am going to do that in the future and I strongly suspect Firefox will bite it someplace around 80 windows or 700+ tabs on a Pentium IV.  (I.e. between Firefox and X you will eat 100% of the CPU).   That should not be the case.  On a reasonable system the program in front of my face gets 100% of my attention.  Everything else gets secondary attention.  If Firefox is not programmed as such it is not programmed properly.

If the last window, or the active window do not have priority than the design is fundamentally flawed.  Even during a 15 minute CPU time suck down during a Firefox restoration the primary active Firefox window should be functional.

And I am talking about Linux here -- I could care less about Windows.

Comment 1

[Wayne Mery (:wsmwk)]

have you tabulated what it takes to load those 338 tabs by themselves, then calculated out what 338 tabs might be able to load in, assuming some limiting factor exists for both cpu and network when loading multiple tabs?

for example, 338 x 5 sec load/tab = 19 minutes.

Comment 2

[Robert Bradbury]

Wayne, are the customers using windows?

If so you can presume they are idiots

Protecting them from their own self-idiocy is difficult.

Comment 3

[Wayne Mery (:wsmwk)]

you comment may be accurate. still, it is decidedly unhelpful

Comment 4

[Robert Bradbury]

Wayne, let us get back to the problem which is just the restart problem.  I have done this in numerous cases where I watch a "Firefox/Mozilla" "state restore" under Linux.  It is always CPU bound for 10-15 minutes(assuming a few hundred tabs) during the restoration process.

Once long ago, I read that there was some kind of setting that involved a page refresh or redraw frequency that could be set but I do not recall what it is.  In any case one might suggest that it should be "reset" during browser "restarts".  One should download each page (tab), not deal with any refreshes, and be done with it, in a reasonably linear fashion.  For example, if my pages are from PubMed (as they frequently are), or from /. as they sometimes are they do not change on a minute-by-minute basis.  Download them and be done with them.  What I want is my browser back in my pre-crash state (all several hundred tabs included).

Leaving aside the CPU time consumption of a browser restart problem, I do notice that a restart does not fully utilize my network bandwidth on a DSL line.  If a restart cannot saturate a DSL line, it certainly cannot saturate a cable line. An optimized program one would expect that a restart would saturate both the CPU and the network bandwidth until all pages were reloaded.

Though I do not know the bug #'s, there are bug reports filed on "hangs" during restarts -- these involve everything from requests for security approval bypasses to FTP timeouts (due to the long restart times). Any time you generate a pop-up window will hang the restart process.)

Comment 5

[timeless]

polite programs do not saturate bandwidth. and besides, we're going to be in i/o-wait most of the time, waiting for the servers to respond.

Comment 6

[Robert Bradbury]

Programs have two distinct modes of operation.  One is "typical", i.e. general browsing, and the network saturation will most probably vary with DNS and/or server response, as suggested.

The second is "atypical", where one is attempting to restore a session which involves hundreds of tabs. I am not dealing with bandwidth limited sites!  I am dealing with the NY Times, Slashdot, PubMed, Digg, etc.  These sites deal with thousands of requests a second.

If I am restoring a session, I have three problems
1) It tends to be CPU bound for 10-15 minutes.
2) It is not network bound (and it should be for at least the first few minutes).  Should a browser when restoring hundreds of tabs not be network bound for the first few minutes (then following the downloads of the pages it should be CPU bound until the pages are redrawn).
3) During the page restoration process Firefox/mozilla should always grant priority to the page in front of my face.  That means downloads, running Javascripts, etc. for pages not in front of my face get pushed into background. I realize this may require a coordination between the browser and the windows management system.  But that is what software may have to do.


I run the Gnome System Monitor on my system on a continual basis and I have a reasonably keen awareness of precisely what is going on on my computer at any point in time.  That allows me to state with reasonable accuracy what the computer is or is not doing at various points in time during a restoration process or a simple browsing session.

Comment 7

[Robert Bradbury]

I have attached a sessionstore.js file to bug #396375 (Attachment #312512 [details]) which provides an example of 10+ minute 100% CPU usage during a session restart.  I have some significantly larger session files but they cannot be attached due to attachment size limits.  If someone wants me to email them one they should send me a direct email address.

Comment 8

[Kim Holburn]

I have seen this problem several times.  On a Mac running leopard.  It starts in one of several ways, either my system crashed or Firefox crashed.  When I start Firefox after this I get the dialog saying: do I want to restore the session.  If I click yes, I get hundreds of windows starting up, filling the screen.  I have never waited for them but try as fast as possible to kill Firefox, which usually takes a while because of all the firefox activity.  I have never waited long enough for any of the windows to actually finish rendering.  One time I had to reboot the system as the activity was causing massive non-responsiveness. Since my sessions only ever have at maximum one window and twenty tabs something is drastically wrong with what Firefox is doing.  

Comment 9

[Kim Holburn]

Sorry: MacOS X 10.5.2 Build 9C7010 Firefox 3.0b5 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Comment 10

[Simon Bünzli]

Kim: That sounds like a completely different issue (Firefox restoring windows that it shouldn't). Please file a new bug, should you be able to reproduce the issue (and after having made sure that it isn't extension related).

As for the issue from comment #0, that's a combination of Firefox opening dozens of windows at the same time, Firefox having to wait for web pages to load, Firefox having to re-layout every single of those pages and Firefox having to execute all scripts/plug-ins from those pages.

Since we're most probably not going to separate tabs or even windows into their own processes (which could then be shoveled over to additional CPUs or even be down-prioritized), it might help to load only about a dozen tabs at a time and then wait for at least half of them loading/being closed before loading the next dozen, etc. until we're done. That's still going to take a lot of time for hundreds of tabs to load, but Firefox should remain more responsive all the time.

An alternative might be to load error-page-like content for all the tabs which automatically loads the actual content after a random interval (and offering the user a button for instantly loading the tabs s/he needs most urgently).

Both alternatives could use the pref browser.tabs.maxOpenBeforeWarn to determine when to start batching the load.

Comment 11

[Robert Bradbury]

I wish to add some comments. First, it would be reasonable to restore windows/tabs in an LRU pattern since that is how I accessed them and is most probably how I want them back.  I realize that this may involve augmenting the sessionstore.js file -- deal with it.

Second, why are the the pages not redrawn and then potentially correccted from pages in the cache?  (Which should require no network activiy!)

Third, why does firefox fail to respond immediately to windows commands to bring it into the "active command window" during the restoration process.  In other words if I open a new firefox window, start a resterotation process (whihch may take 15+ minutes), why can I not immediately go to www.slashdot.org?  (The network bandwidth limitation arguments fail here as I can watch the network bandwidth be consumed and there are times where it is high (in which case it should be multiplexed) and times where it is low.)

Finally, I wish to comment that if you are failing to restore sessions within what is known as "workspaces" under Gnome (I normally operate with 9+ workspaces) and many Firefox windows belongs to its individual workspace -- then you are failing to properly restore Firefox.

Comment 12

[Jesse Ruderman]

Fixed by bug 586068?

Comment 13

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #12)
> Fixed by bug 586068?

Hopefully since this bug seems to be about Firefox becoming unusable. It seems like bug 586068 actually implemented Simon's idea from comment 10, so win!

Robert, can you give a recent Firefox 4 beta a try and see if that helps alleviate your issues?

Comment 14

[antistress]

Indeed, Firefox 4's Cascaded Session Restore feature solves this bug from my point of view

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to comment #14)
> Indeed, Firefox 4's Cascaded Session Restore feature solves this bug from my
> point of view

Much better for me also. 5.0a2 starts like a dream on my win7 8GB machine using Ray's sessionstore.js file from bug 396375.

Comment 16

[u279076]

Thanks.