Created attachment 298330 [details] Test repeated loading of the NY Times home page. The comments in the shell script are fairly self-documenting. As the NY Times is running refreshes of its home page every 15 minutes the goal is to open sufficient sessions to that page to force extremely frequent refreshes of one or more of the resulting sessions. This requires opening several hundred tabs but as the comments discuss Firefox has a difficult time doing that.
Severity may not be critical according to guidelines. Major might be more suitable. (I'd be more useful if I had a single-core cpu).
Its not that the bug will not appear on a multi-core CPU, its just that I have no way to try it currently. Doubling MAXSESSIONS and decreasing INTERVAL to 3-5 seconds might be a good place to start. It should be noted that I started with an INTERVAL of 5. That worked ok on the single (semi-dual) core Prescott up to 50-100 sessions. An INTERVAL of 3 hung at less than 50 tabs. Of course this is dependent on your browser-to-web bandwidth (e.g. DSL vs. Cable) the load on the line and how fast your DNS lookups are (the NY Times is serving from multiple servers) and whether or not the NY Times constrains bandwidth to a specific IP address (I doubt they do given the fact that internal nets may all look like the same IP address to the NYT). The point would be to decrease INTERVAL and/or increase MAXSESSIONS until one gets to the point where one has multiple sessions loading simultaneously -- if problems (hangs or delays in loading) arise then you have encountered the problem. If one decreases INTERVAL to 1 and increases MAXSESSIONS to 1000 and it still works then one would have to write a Linux shell timeout program that works in milliseconds rather than seconds. My indications currently are that you will max out a single (semi-dual) core CPU around 250 tabs. So even with a quad core you should max out with 1000 tabs.
Created attachment 298345 [details] Updated NYT-test.sh script Updated script, essentially corrections or expansions to the comments.
Attachment #298330 - Attachment is obsolete: true
Are these results with trunk or with v2? Results would be more relevant and useful from a development perspective if done with trunk, and possibly compared to v2. And, I would suggest, install flashblock extension and see if you get different results.
Wayne, I do not recall. I suspect the initial bug report would contain the details. I usually run the production release of Firefox but from time to time wrestle with the prerelease versions. However the test case is very clear and can be used to effectively take down the browser. It should not be possible to take down a browser by bringing up several hundred identical windows from one of the major newspapers in the U.S. It should not be required to install a "flashblock" extension since I had already disabled gtk-gnash on my computer due to firefox's poor handling of flash extensions (for example limiting the runtime of flash scripts or collecting the child processes after termination). In a reasonably behaved browser, flash players should be limited to reasonable behaviors. As it appears advertisers, media producers, etc. want to keep shoving things through our eyes, there should be clear ways (in the default browser) to prevent this.
Ray, flash player is well documented to have *numerous* problems in the past few years (yes, as has firefox). What do you get with Firefox 3, and flash v10? And if it fails, results with flashblock?
Version: unspecified → 2.0 Branch
at this point, testing with FF2 and even 3.0 are not useful, given the nearness of 3.1. please test with 3.1 beta - with and without flash 10 (flash 9 is history). http://www.mozilla.com/en-US/firefox/3.1b2/releasenotes/
Severity: critical → major
Whiteboard: closeme 2009-03-01
=> incomplete without further feedback.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.