689898 - Opening many tabs within short time may cause firefox to stop loading new web pages at all

Status: RESOLVED DUPLICATE of bug 692260

(Core :: Networking: HTTP, defect)

Description

[yu_icq]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110922153450

Steps to reproduce:

(a) Artificial reproduction / Everyday usage case
o Created new Firefox profile
o Go to page with many links, e.g. http://en.wikipedia.org/wiki/Firefox#References
o Shift-Click the links in rapid succession.

(b) Original occurence
o Created Cygwin bash script to open 48 URLS in firefox (reading URL list from file) by executing `firefox 'URL'` or `firefox -new-window 'URL'` for each URL, waiting 8 seconds after each URL.
o Ran the script.


Actual results:

Some of the tabs completely load. Some load partially. Some don't load at all. 

Once there are stalling tabs and even after /closing/ those tabs, the CPU utilization by firefox will stay around 50% (100% on one core) forever. Webpages will no longer load or, at least, render, in new tabs and existing loaded tabs alike.

Reloading (F5) or stopping loading and pressing [Enter] in the address bar again will not help.

Restarting firefox will have the tabs stalling again.

Removing stalling tabs before restarting resolved the problem, but means losing the tabs rather than just reloading them.

Using the "Load Tabs Progressively" Addon prevents the problem, but can be sabotaged by tabbing through unfinished tabs. Having to wait for the tabs to finish loading before going there makes the expierience extremly slow though, more than manually avoiding loading new tabs too quickly. Neither is it fully reliable even then, unless set to "only 1 tab loading concurrently" (which feels even slower). 


Expected results:

The tabs should just have loaded, given enough time.

The problem can be avoided by waiting after opening a new tab until CPU utilization normalizes again (i.e. usually until the new tab(s) have loaded). I cannot give a reliable number of tabs, that may load at the same time without causing the problem - it seems to vary. 

=== Additional Information ===

OS: Windows 7 Home Premium 32bit
Firefox-Version: 7.0
CPU: Core 2 Duo T6400 2.00 GHz

Comment 1

[yu_icq]

The problem just got bigger: With 50 tabs open, it seems quite impossible now to avoid this problem when restarting the browser.

o It did work at the university (high speed, low latency connection)
o It doesn't at home (6MBit but slightly laggy).

It seems, problems appear when pages cannot be processed sufficiently fast.

Comment 2

[yu_icq]

With Firefox 6.0 I could not reproduce the problem.

Comment 3

[yu_icq]

With Aurora 8.0a2 I could reproduce the problem again.

Comment 4

[Wayne Mery (:wsmwk)]

yu_icq, I don't see this when using current trunk 64bit and windows 7. 

can you reproduce when started in safe mode?
 http://support.mozillamessaging.com/en-US/kb/safe-mode
with version 9 or trunk(10)?

Comment 5

[Wayne Mery (:wsmwk)]

I should add, I seem something similar if I use the addon snaplinks plus or multilinks, and open multiple links - sometimes as few as 10.  But I've not been able to determine whether the problem is the addons, or firefox.

Comment 6

[yu_icq]

I tested the problem now in Safemode. Not much changed. 

Apparently it didn't make any difference, wether the session was running when executing the command or if it was started by the command.

With the following command run while the corresponding Firefox session was opened already...
... Firefox 6.0 was able to load all pages. 
... Firefox 7.0.1 exhibited the described problem as before, necessitating browser restart.
... Aurora  8.0a2 exhibited the described problem as before, necessitating browser restart.
... Aurora  9.0a2 exhibited the described problem as before, necessitating browser restart.

With the command run to start the Firefox session...
... Firefox 6.0 was able to load all pages.
... Firefox 7.0.1 was able to load all pages in one case, but failed in all others. (I suspect that in the case it worked, I accidentially had the pages still in the cache.)
... Aurora  8.0a2 exhibited the described problem as before, necessitating browser restart.
... Aurora  9.0a2 exhibited the described problem as before, necessitating browser restart.

The command (run in cmd.exe in the different installation folders): 
firefox "http://www.rietta.com/firefox/Tutorial/backend.html" "http://davidwalsh.name/firefox-internal-rendering-css" "http://userstyles.org/styles;app" "https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/" "http://www.mozilla.com/firefox/all.html" "http://www.mozilla.com/en-US/legal/eula/" "http://web.archive.org/web/20070528164713/http://www.mozilla.com/en-US/legal/eula/firefox-en.html" "http://lwn.net/Articles/118268/" "http://www.w3counter.com/globalstats.php" "http://www.ranking.pl/en/rankings/web-browsers.html" "http://www.mozilla.com/firefox/geolocation/" "https://addons.mozilla.org/firefox/browse/type:1/cat:all" "http://www.mozilla.com/en-US/firefox/7.0/releasenotes/" "http://en.wikipedia.org/wiki/Ben_Goodger" "http://en.wikipedia.org/wiki/Brendan_Eich" "http://en.wikipedia.org/wiki/Dave_Hyatt" "http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.html" "http://web.archive.org/web/20070914035447/http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_Mozilla0" "http://www.techworld.com.au/article/64477/mozilla_dirty_deed_brings_firey_response" 

=== New knowledge ===

- When the problem occurs, the "Searching for Updates" in "Help>About
  Firefox" doesn't finish either, so I suppose it's not a problem with
  rendering but with retrieving data.
- Stopping the loading of the hanging tabs with ESC before closing
  them doesn't resolve the problem without browser restart either.

Note again: Im running a 32bit Windows 7 (though for reasons unknown to me - the Hardware is 64bit capable but Sony preinstalled a 32bit version of Vista, thus I was only aligible for the 32bit upgrade version).

Comment 7

[Patrick McManus [:mcmanus]]

yu_icq - thanks for reporting this. If you can add your dll info over in 692260 we can maybe figure out what is really going on.

(it isn't just a matter of lag inducing parallelism - we've got a test case that does that and not everyone exhibits the problem.. so hopefully we can figure out what is going on in your environment that causes the problem.)