firefox hangs when it loads a page in the background

Happens to me as well on a slow computer with Win98. This ussualy happens when I
have quite a few tabs open already.

I am a very long-term Mozilla user who just switched to Firefox couple of hours
ago (I am using firefox-1.0-2.fc3 from Fedora Core 3 updates on an FC3 machine)
and I see this as well, with windows instead of tabs. Every time I open a new
link anywhere, all Firefox windows freeze for a few seconds - _very_ annoying!

Additional information:
- I imported my settings from Mozilla (last Mozilla that touched that was a
recent CVS trubk build)
- I use proxy (squid on localhost) for all my browsing

I am unable to reproduce this behaviour on Win XP Pro with Firefox 1.0 or on a
dual Intel Xeon Fedora Core 3 running Firefox 1.0-2.fc3 (via squid proxy and
direct). Would it be possible to get cpu and memory stats on both the running
process as well as system when this occurs?

The win98 problem could possibly be caused by lack of memory as he does mention
it is a slow machine and that it only occurs with lots of tabs open already.

The other two are both linux cases however. Could you please give further info
such as processor, memory and display manager and of course the cpu stats I
mentioned.

I am pretty sure that mine is caused by a very large history file - see bug
223476 for more detail. I have a 1.8Ghz P4 with 512MB of RAM. When Firefox
freezes, CPU utilization goes to 100%, memory utilization seems OK.

I assume that when you clear the history file this solves the problem then?

(In reply to comment #0)
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041026 Firefox/1.0RC1
> Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041026 Firefox/1.0RC1
>
> when i click with middle click or strg-click on a link to open this link in a
> new tab in firefox 1.0rc1, the brwos freezes 3-10 seconds before he react and
> open and load the tab! in this 3-10 seconds i can't do anything in firefox! go
> to http://www.spreadfirefox.com/ and test the links on the right of the page! it
> happens to me not every link, but very often!!!
>
> Reproducible: Sometimes
> Steps to Reproduce:

Yea, I seem to get this a lot. And it seems to be getting worse. I am sure
however that it is from a large history file.

I'm also seeing this problem. I have a small history file (about 100k). Open
link in new tab and get a nice3-5 second freeze up of browser. Seems it locks
tight while trying to resolve the link...

Hi,

I get this ALL the time. It is not (just) a gecko problem or a DNS resolver
thread problem.

How to reproduce: open a number of tabs (preferably complex sites, eg. yahoo or
slashdot)

Reproducable: always

Result: Cursor changes to hourglass. Complete Firefox application freezes for a
few seconds, other tasks are not affected.

Expected Result: Tab may load/freeze but rest of Firefox (e.g.: other tabs,
menu) should still respond.

- It is not the history file (cleared that, restarted, problem remains).

- It is not a local proxy problem (problem remains with and without squid and/or
privoxy or direct)

- It is not version dependant (can be reproduced with Mozilla 1.7x, Firefox
1.0-1.0.3, etc., seems to happen in Thunderbird as well not sure)

- It is not Hyperthreading relevant:
https://bugzilla.mozilla.org/show_bug.cgi?id=277547
I do not not have an HT intel chip.

Assumption: It seems to be that Gecko "hangs" a bit on pondering the layout
complex pages (e.g. Slashdot) before rendering starts. This may also happen
when rendering has started and sub-sections of the page need to be rendered.

My personal analysis: That Gecko hangs is not the real problem however. What
the user expects is that on opening a new window/tab is that Firefox starts a
new Thread for that window/tab and even if the "new" tab hangs he should still
be able to use his present tab or access the menu commands.

Sugested resolution: add a new thread for each tab/window. (Assuming my
analysis is correct).

Cheers,
  Duncan

PS: I think Bug #248345 is a dupe of this bug, 277547 may be as well but perhaps
there are HT issues I don't know about.

(In reply to comment #8)

Did a little more testing, reproducible on a WinXP-home-sp2 (2.8Ghz, 1GB) system
and debian-sarge 1 GHz, 256MB.

The Gecko hang happens exactly after the tab gets opend and starts the rotating
mini icon, but just before the gray background get its first layout rendered.
Could be a hang in CSS layout?
It is not history or font related as I ruled that out.
Again, the short tab/window-freeze is annoying but not as annoying that the
_entire_ application is frozen.

The problem could not be easily reproduced on my office system: WinXP-Pro-sp1,
Laptop 1.6 Pent-M, 1GB. I do get a short (less than 1 second) hang on complex
pages (e.g. http://www.unika.com.cn/) but not the 3-10 second hangs I regularly
get at home.

So the problem still asserts itself but not to the same "very-annoying" wait
time as I get on my system at home. Any suggestions?

Cheers,
 Duncan

PS: suggest adding the keyword: qawanted
PPS: suggest changing OS from "Linux" to "All"

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3)
Gecko/20050714 Firefox/1.0+

is it possible that i comes from the dns request? (maybe you can do that in the
background???)

(In reply to comment #11)
> is it possible that i comes from the dns request? (maybe you can do that in the
> background???)

No, this is not a DNS request handling problem (though we still have a bit of
those elsewhere). This hang occurs after the connection is established but
before the page is properly rendered.

I have a suspision the "hang" occures if the internet connection is under
high-load (e.g. router out of connection space or bandwidth is full). Then the
rendering engine (gecko) hangs the whole application until new data is recieved.
 I am not quite sure how to test that conclusivly though...

In any case: each Tag should run under its own thread/task so that the entire
application does not hang because one tag/window is hanging.

Cheers...

PS: Please remember to "Vote" for this bug to insure it gets fixed sometime!

ot: why must we vote for a bug which is a blocker imho?!

ps: i've voted for this bug...

I have rechecked for router/tcp congestion causing this problem (e.g. ack
packets not getting through). It seems this will slow down firefox (or any
network application for that matter), but is not the cause of this hang in firefox.

That leaves something in Gecko hanging after the tag has opened but just before
initial rendering starts being the cause... IMHO.

Blake, have you looked into this yet?

Found a way to make it always reproduceable:
Set Homepage to: "http://gameguru.box.sk/|http://www.gamespot.com/pc/"

It seems that the complexity of the layout causes Gecko to freeze during some
opereration, which in turn freezes the entire application.

Suggest adding Keyword: "clean-report"

Somebody set:

Bug 266627 depends on: 245745 (history bug)

That is incorrect. This bug is not related to the "history" performance error.
 This is a gecko-threading bug.

(In reply to comment #15)
> Found a way to make it always reproduceable:
> Set Homepage to: "http://gameguru.box.sk/|http://www.gamespot.com/pc/"

http://gameguru.box.sk/ and http://www.gamespot.com/pc/ do not cause problems for me on XP in FF 1.5. Please test in FF1.5 or a nightly build and report back with build string.

(In reply to comment #17)
> (In reply to comment #15)
> > Found a way to make it always reproduceable:
> > Set Homepage to: "http://gameguru.box.sk/|http://www.gamespot.com/pc/"
>
> http://gameguru.box.sk/ and http://www.gamespot.com/pc/ do not cause problems
> for me on XP in FF 1.5. Please test in FF1.5 or a nightly build and report back
> with build string.
>

Still happens with 1.5: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5. It's not the machine: 2.8 GHz, 1.25 Gigs RAM... Hell I don't know. If this was unix I would turn on a debug log to see what the hangup is... don't know how to do that on windows. :-(
I still think it's geckos fault, some timeout during initial page build but that is just a guess.

works fine in my linux (slamd64, 32bits mozilla binary, 1.5)
are you using any extensions?
any special(or lack of) plugin support?
does it happen just after starting firefox (with no pages open) or after sometime?

have you tried with a clean profile?

(In reply to comment #19)
> works fine in my linux (slamd64, 32bits mozilla binary, 1.5)

See notes 8,9 and 14. It is platform independant. Not font or history related. Not dependant on hardware config. Tab/window opens, background gets painted single color, hang happens just before initial rendering starts.

> are you using any extensions?
> any special(or lack of) plugin support?

Happens on clean install as well as with extensions/plugins (all versions all release candidates and final 1.5 verion).

> does it happen just after starting firefox (with no pages open) or after
> sometime?

Right from the beginning and during regular use (when opening new tabs/windows).

> have you tried with a clean profile?

Yes. Cleaned out everything, clean install. Open firefox, set home page to complex site. Start firefox again: complete hang of about 10 seconds.

Complex sites highlists the problem. DNS waits and network congestion aggrevate it, but do not cause it. So it is most likly a timeout problem in Gecko or code close to Gecko.

There must be something I am missing. Unfortunatly the orignal posters didn't say enough for me to figure out the common issue between their and my setup(s).

The question is: which piece of code (in the original Firefox package) LOCKS the whole application AFTER a tag/window/frame has been opened, the DNS lookup is done, the tag name and the grey background has been painted the throbber has done a round or two; BUT just BEFORE the first rendering starts (see also comment #8).

Which piece of code there could run into a timeout situtaion in which it completely locks the whole applciation between 3-60 seconds (usually about 3-10).

<Disclaimer: I am not a coder/programmer>
I would expect this sort of code in Gecko caching code, rendering preparation code, network access code or the glue code between Gecko and Firefox.
</Disclaimer>

I suggest the early comments be ignored and start fresh. comment 1 has no useful information. Certainly comment 2 and say so. In addition, in retrospect Aleksy should should not have confirmed the bug so quickly at that time, as it turned out his/her problem was an unrelated issue.

Secondly I doubt these are all the same problem. The .cn site obviously (IMO) has server speed issues. just reload the website and you can see it renders much faster.

Also speculation about what the problem IS or is not (gecko, etc) is not helpful until a reliable testcase / test url is provided that multiple people can recreate. That means every comment should cite what url they are talking about and the exact state of their machine. (out of time for now)

mslee - does bug 248345 describe your problem?

(further info on http://www.unika.com.cn/ - it pegs cpu at 25% on my small machine just idling - probably due to it's animated images - a seperate bug. Even better indication that it may be a bad test case due to that interference (plus the server delevery speed delays). copy the page to the PC and see if the slow speed problem still shows.

Do same with other pages that result in poor performace. Do they render slow if loaded from the PC (rather than the net)?

If you can, test your URL with IE (or other browser) before commenting. Also, see Bug 277547 if your cpu has hyperthreading or multiple cpu.

It has been suggested that this bug be closed WFM because
a) Alexsey the confirmer states his/her problem was 'history' (so it should not have been confirmed at that time)
b) the bug is digressing into problems with other links and issues (some of which are not limited to unix)
c) several unanswered questions related to mseele's report using the initial URL:
   - does it happen if just clicked (rather than middle clicked)
   - does it happen with FF 1.5 or trunk
   - does it happen just with linux
   - does it happen of not using tabs

Perhaps it is wise to close the bug and address individual issues (causes) in new bugs focused on specific issues or in one of the many existing bugs https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywords&short_desc=perf+performance+slow+cpu+high+freeze+freezes&product=Core&product=Firefox&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&op_sys=Linux&chfieldto=Now&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=mail

If nothing else, assuming this is a linux only bug, then examples that fail in windows and other OS don't help this bug - and should be taken elsewhere. Complexity and complex example sites also make finding the cause more difficult. A developer is probably not going to touch this unless the problem can be reduced.

Bug 248345 suffers similar issues. Still, Linux users might want to check it.

(In reply to comment #24)

> a) Alexsey the confirmer states his/her problem was 'history' (so it should
> not have been confirmed at that time)

Actualy, I am not certain that my problems are history-related. Yes, I have a large history files, but now that I am using 1.0.7, I usually do not get any unusual delays. Except sometimes, I start getting it on _all_ URLs in all window and have to restart Firefox to get rid of it...

(In reply to comment #22)
> I suggest the early comments be ignored and start fresh.

Original poster (mseele) laid out the users view of the bug very well.

Bug Description: Open new site in a Tab: Firefox freezes for 3-10+ seconds _exactly_ after the tab/window gets opened, the title name and grey background have been painted and the throbber starts rotating, but just before the first rendering is performed. The status on the bottom says: "Transferring data from <site>...".

Note: it usually happens when a new tab gets opened, but I have been able to reproduce the problem on new windows (right click, open link in new window) and have been able to see it happen after part of a multi-frame page got loaded and a further frame needed to be rendered. As the hang in the latter (frame rendering) case looks exactly like the Tab freeze I assume it is the same bug.

No other parts of the system are affected (e.g. no undue cpu load, no memory problem, other applications work fine... everything else is perfectly normal).
It happens under heavy and no load, with or without strong network traffic, with and without other programs running.

It is an intermittent problem: the only thing I notice is that when it happens: it is repeatable for a while (hours or the next one or two days) before it goes away. Also when I use the IE browser on the same sites, this does not happen! It also happens with Galleon under Linux but I have not tested that as intensively and no longer have that installed.

Bug happens on 3 different machines:
1) WinXP-sp1 (and sp2) Laptop PM 1,6 GHz, 1 GBytes
2) WinXP-sp2 P 2,8Ghz, 1.25 GBytes
3) Linux (Debian Sarge), P 1GHz, 256 MBytes

On any complex site URLs. Try: www.yahoo.com, gameguru.box.sk or gamespot.com

Happens with Firefox 1.0, 1.0.5, 1.0.6, 1.0.7, 1.5 RC1-RC2 and 1.5 final
Example Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

_Ruled_out_ (see other comments): hyperthreading (#277547), version dependancy (see browser list above), OS dependency (see OS list above), processor dependency (except that all my processors are Intel), load dependency (happens under high and low load), low memory issues (stilL have 700-800 Megabytes of RAM left), DNS problems (did multiple tests on that), proxy problems (with or without proxies), network congestion timeout (different networks at different times using different connections with high throughputs and response times), font problem, history problem (cleared history), animated images (happens on sites with just text), extensions and plugins (clean install).

Example for freeze that rules out DNS timeout: One tab on slashdot, another on "http://www.sortasoft.com/index.php". I middle-click on "Other Games" to get this page in a new tab: http://www.sortasoft.com/othergames.php and my Firefox froze for 4 seconds.

Things that aggravate the problem: complex page builds make this more likely, network congestion or low bandwidth makes it more likely to happen.

Things that help: restart firefox (problem often reappears quickly though)

Suspected dupes of this bug: 248345 (has some good comments), 266627

Final words: all tests mentioned above have...

This is by far my largest gripe with firefox. The user expects that when they load new tabs in the background, it should not interfere with the operation of the whole application. On the two machines I use predominantly (one is Firefox 1.0.7 on Fedora FC4 / dual 500MHz PIII / 512MB RAM, the other is Firefox 1.5 on a FC4 / 3 GHz P4 / 2GB RAM, both approx 256kb/s connection), I get this happening all the time.

I am sorry to say the deer park nightly builds (up to 31 March 2006) as well as the new "Bon Echo" alpha build for FireFox 2.0 _still_have_the_bug_.

I am contiously testing against new the builds because Wayne Merry told me:
> The gecko/DOM bugs are now fixed on the trunk. So now would be a good
> time for you to try these tests using a trunk build and update the bug.

I have been able to create a reproducible test situation using a starved proxy process on a separate machine to slow network transfers to a crawl. This setup does not allow for simulation of the complex pages though, but that may have to be filed as a different bug or wait until this jang the "Transfering data from <site>" bug gets fixed.

Resumee:
Firefox still freezes for 3-10+ seconds _exactly_ after the tab/window gets opened, the title name and grey background have been painted and the throbber starts rotating, but just before the first rendering is performed. The status on the bottom says: "Transferring data from <site>..." (this is after the "Waiting for <site>..." status).

perhaps? this will help bug 326273

(In reply to comment #29)
> perhaps? this will help bug 326273

Duncan,
can you try an experimental build created for bug 326273 (it will introduce other problems but it would be interesed to see if it resolves THIS bug) http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/threadmanager/

> Things that help: restart firefox (problem often reappears quickly though)
> Suspected dupes of this bug: 248345 (has some good comments), 266627

bug 248345 no longer applies as it has been duped to "large history file".
did you have another bug in mind? (perhaps you meant something other than bug 266627 cited above, which is this bug :)

you state restarting FF helps - does "clear private data" also help?

perhaps time to try the newest nightly build. And, without a clear cause or pointer to the cause and no objective data in the form of a debug or protocol log, you need to either eliminate more possibilities and/or go in search of other similar bugs.

So, changing component to tabbed browsing and suggest you attached an http log* and document a test case with steps and URLs.
* http://www.mozilla.org/projects/netlib/http/http-debugging.html

(In reply to comment #31)
> you state restarting FF helps - does "clear private data" also help?

No.

> So, changing component to tabbed browsing and suggest you attached an http log*
> and document a test case with steps and URLs.
> * http://www.mozilla.org/projects/netlib/http/http-debugging.html

Thanks for the tip!

Test case, homepage URL:
http://images.google.com/imgres?imgurl=http://www.tkcsusa.com/eniac_3.full.jpg&imgrefurl=http://www.tkcsusa.com/&h=426&w=524&sz=53&hl=en&start=107&tbnid=-8farRS2GyQt2M:&tbnh=104&tbnw=129&prev=/images%3Fq%3Dipod%2Bmusic%2Bad%26start%3D100%26ndsp%3D20%26svnum%3D10%26hl%3Den%26lr%3D%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26sa%3DN

Using slow proxy to simulate slow network connection. Which makes the bug easier to reproduce (see previous posts).

Current Internet Explorer takes 8 seconds to load this page. However at all times IE stays responsive. In other words, I can use the menues, open new windoews, etc.
(6.0.2900.2180.xpsp_sp2_gdr.050301-1519)

Firefox 1.5.0.5 takesl 11.51 seconds to load this page, including an 8 second freeze in which "Not Responding" apprears in the window border!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060725 Firefox/1.5.0.5

As aways "transfering from..." is given in the status window so the bug happens after DNS resolving. See previous post for exact FF behavior.

Used:
set NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5

Here is the log:
http://www.mcnutt.org/duncan/firefox%20bug%20266627%20log%201.txt

Is there a way to add a timestamp to each log entry? That would make finding the place at which the error occurs easier.

it happens to me when i try to play a game.

(In reply to comment #25)
> Except sometimes, I start getting [delays] on _all_ URLs in all
> window and have to restart Firefox to get rid of it...

This sounds a lot like symptoms I reported in Bug 233872:
https://bugzilla.mozilla.org/show_bug.cgi?id=233872#c12

My guess is that the underlying problem is in memory allocation code that wraps the OS memory allocation system calls (assuming Mozilla has its own malloc wrappers) or some higher layer abstraction, like an in-memory database (doesn't Mozilla use RDF structures for a bunch of things?). The "threshold" I referred to seemed to vary depending on the platform, and what extensions are loaded, but usually using the browser for an extended period or stressing it by loading complex pages will cross the threshold, after which performance tanks. The problematic code may be part of the JS engine, as sites that have JS complexity are more likely to trip the threshold, and once past the threshold, UI interaction that is implemented in JS (like switching tabs) crawls. It could be due to some inefficient code similar to Bug 40988, except instead of speed decreasing exponentially as number of DOM nodes increases, it may be relative to some other internal memory structure.

The situation has gotten so bad with my current FF installation (I haven't determined whether it is FF 2.0 itself, or the increased quantity of extension) that I've had to reserve using FF for development, and have switched to using a (ironically) light-weight Seamonkey installation for day-to-day browsing.

 -Tom

mseele (michael), can you attach an http log as duncan did? Cite the URL you use to test. Instructions at http://www.mozilla.org/projects/netlib/http/http-debugging.html - duncan used:
set NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5

mseele wrote me on 6/20/2006 "yes it is [a problem] (i use the 1.5.0.4). i thinks it comes from a long dns-lookup or something like this." so it may be a localized problem.

Question - do you see the same behavior if you paste the URL in a new browser window immediately after starting FF? instead of opening through a tab or a link from another page?

Duncan, unfortunately the URL you used to test no longer works.

Tom in comment #34)
> Aleksey Nogin in comment #25
> > Except sometimes, I start getting [delays] on _all_ URLs in all
> > window and have to restart Firefox to get rid of it...
>
> This sounds a lot like symptoms I reported in Bug 233872:
> https://bugzilla.mozilla.org/show_bug.cgi?id=233872#c12

Alexsey doesn't say if this started immediately upon opening. What you describe in bug 233872 develops over time and is related to a combination of flash, garbage collection and huge memory usage that increase with time - well described in flash bugs. This bug is described as happening as soon as FF is opened.

> It could be due to some inefficient code similar to Bug 40988

Bug 40988 is about the creation and destruction of certain java data structures. My guess is not related to this bug. Perhaps to Alexsey's - but we don't have any URLs form alexsey to test.

p.s. flashblock extension will help avoid memory problems related to flash images - I would guess better than adblock in this context.

(In reply to comment #35)
> Tom in comment #34)
> > > Except sometimes, I start getting [delays] on _all_ URLs in all
> > > window and have to restart Firefox to get rid of it...
> >
> > This sounds a lot like symptoms I reported in Bug 233872
>
> Alexsey doesn't say if this started immediately upon opening.

True, though it is strongly implied in the wording he uses. "start getting" implies it is working OK and then degrades, and "restart Firefox to get rid of it" implies a restart at least temporarily cures the problem.

> What you describe in bug 233872 develops over time and is related to a
> combination of flash, garbage collection and huge memory usage that increase
> with time - well described in flash bugs.

Your other assertions may be true, but what I observe is unrelated to Flash as I never install Flash on my FF installations.

> This bug is described as happening as soon as FF is opened.

That isn't explicitly stated by the original poster, and my interpretation of Aleksey Nogin's comment #25 is that he was describing a problem that develops over time. You could make a case that both what Aleksey Nogin and I describe is a separate problem for another bug report. Can you suggest a more appropriate ticket that isn't Flash related?

> > It could be due to some inefficient code similar to Bug 40988
>
> Bug 40988 is about the creation and destruction of certain java data
> structures.

More correctly, JavaScript.

> ...but we don't have any URLs form alexsey to test.

That's the problem. The test case isn't as simple as a single URL. It's hundreds of page retrievals. And multiple variables involved (browser version, page complexity, extensions). Though sites like:
https://www.discovercard.com/cardmembersvcs/loginlogout/app/ac_main

seem to exacerbate the problem. Maybe I'll look into creating a JavaScript test case that retrieves unique pages (say going through sequential ISBN numbers at Amazon) in a loop, and see if it is repeatable.

 -Tom

- I do have flash plugin installed, not sure if this is related

- Lately, I have not been seeing this often (I do still regularly get the history-related problems of bug 223476 - e.g. every time I accidentally click the "Go" menu).

- When this problem does occur, it is sudden (not gradual) and does not happen on startup.

(In reply to comment #37)
> (In reply to comment #35)
> > This bug is described as happening as soon as FF is opened.
>
> That isn't explicitly stated by the original poster

It's true Michael didn't qualify it. It would be good of Michael to comment here. His statement "happens to me not every link, but very often" plus Duncan's led me to believe it takes very little to set it off.

> and my interpretation of
> Aleksey Nogin's comment #25 is that he was describing a problem that develops
> over time. You could make a case that both what Aleksey Nogin and I describe is
> a separate problem for another bug report.

skip Aleksey's case until flash is eliminated with flashblock and there is a URL or set of steps. Better anyway to stick to just a couple controlled, well known scenarios. See comment about Duncan below.

> Can you suggest a more appropriate ticket that isn't Flash related?

no but there are plenty you can research. bz search and add condition of summary..."does not contain"...flash - here's one limited to linux http://tinyurl.com/28jls2

> > ...but we don't have any URLs form alexsey to test.
>
> That's the problem. The test case isn't as simple as a single URL. It's
> hundreds of page retrievals. And multiple variables involved (browser version,
> page complexity, extensions). Though sites like:
> https://www.discovercard.com/cardmembersvcs/loginlogout/app/ac_main
>
> seem to exacerbate the problem. Maybe I'll look into creating a JavaScript test
> case that retrieves unique pages (say going through sequential ISBN numbers at
> Amazon) in a loop, and see if it is repeatable.

Doesn't matter how complex the problem is - it must be reduced, by magic and if that doesn't work by brute force. A test case, even one URL *with a set of numbered steps* is key.

Suggest you and Duncan team up.

Also I would seriously reexamine whether this is tabbed browser issue. I think someone said it happens in non-tabbed situations.

Hpeens to me too.
FF 2.0.0.1 on Win2003SP1

I middleclick on a link on a forum site ano after another quickly, but on each click it freezes for a few seconds. Also the CPU usage goes to 100% in that time.
I uninstalled flash and all extensions. Did not help, but it was good for a while after the restart.
Does not happen all the time. I suggest browsing around with multipl tabs open (4 to 10) and opening link with middle click one after another.

It happened often on this site : http://www.mobisux.com/tabla/ubbthreads.php

It appears turning off JavaSh^H^HScript helps.

I experienced the problem again, turned off JavaScript in prefs and now it is much smoother.

Argh... forget it.

After a few minutes I started getting even worse freezes (up to 5 seconds, while there were like 1-2 before).

I can confirm the bug too.

It happens to me on Fedora Core 6 on:
firefox-1.5.0.10-5.fc6
firefox-2.0.0.3
swiftfox-2.0.0.3

I have kernel 2.6.20, and an Intel Centrino Duo. Would that have anything to do with it?

This site makes things specially slow:
http://www.mobisux.com/tabla/ubbthreads.php

Reproduced on WinXP SP2, Firefox 2.0.0.2, seen it also on many previous versions.
Happens in safe mode also. Reproduced on double Xeon 3GHz machine with 2 gigs of mem, i.e. it is not a slow PC issue.

The most slow experience for me is to open http://symbiansmartphone.blogspot.com/
Firefox is frozen several times when rendering this page, totally for up to 30 secs.

Whoa! that page really bogs down Firefox.
http://symbiansmartphone.blogspot.com/

I also found that when I'm playing something from last.fm, and then I open another page the music stops for a while.

Could this have something to do with synchronous DNS lookups?

I wonder if it is possible to change the "OS" for this bug entry from "Linux" to "All"? Apparently it is not a Linux only bug

I have tried the same page in another computer, Firefox 2.0.0.3 in a Fedora 7 test3 on a Pentium 4.

It loads just fine, takes a while, but Firefox is still responsive.

So could it be the processor?

I tried accessing http://symbiansmartphone.blogspot.com/ from three different computers: my home PC - rather powerful Athlon, my work laptop - rather powerful as for a laptop Thinkpad T41, and my work desktop - mega-powerful double Xeon. I used virtually the same set of extensions, the same theme, same anti-virus software (on the work computers), even the same bookmarks/cookies synchronized over the Google Browser Sync.

The bug is reproducible only on my mega-powerful main work desktop. However, there it is reproducible every time and it is huge.

Is there any way to take some logs from the Firefox so that I could post them here?

P.S.
It is not extension problem for sure since on that main work PC I've seen the bug many times with different Firefox versions, with different set of extensions and also in the safe mode with all the extensions and themes disabled.

I found that the bug happens only, when Firefox is configured to use my intranet automatic proxy configuration URL. If I use a direct proxy, the bug disappears.

Apparently the problem is about slow parsing the complex proxy configuration script or with waiting until the new script version is downloaded

I have no proxy but direct connection and still have the problem.
(FF 2.0.0.4 on Win2003)

Indeed, by using direct proxy I don't get the the usual lock. So yes, probably it's the proxy configuration script parsing.

I have noticed similar locks on other systems, but not on the pages mentioned on this bug report. I think on those cases the Flash plug-in is the one to blame.

Tom and David Balažic seem to have the problem. Artem and Felipe have another problem.

Check comment 26 for what we are trying to find: https://bugzilla.mozilla.org/show_bug.cgi?id=266627#c26

If you have hyper-threading, font, histroy, flash, proxy or other problems then you should not report in this bug, find some of the other threading bugs and report there. I believe most have been fixed apart from one proxy and perhaps a new hyperthreading problem.

This is a threading or network access (https://bugzilla.mozilla.org/show_bug.cgi?id=266627#c28) issue in Mozilla/Gecko based browsers on all operating systems, certainly regular users have managed to get as close as they can. IMHO we need to get a Dev involved to try to track this down.

Beats me why it still says "Linux", obviously anybody who can change that flag is not reading the bug base... :-(

I would change the name to "Gecko based browsers freeze 3-10 seconds every time i open a link" if I could, as it happens too Galleon and in new windows (e.g not just tabs) too.

Hmm, Artem's comment about the hang/freeze only happening on his mega-powerful PC got me to thinking: I know for a fact that my upgraded 2.8GHz CPU is not entirely in synch with the original BIOS version of my PC (which was for a 2.0GHz), so I very occasionally get a little XP-related weirdness happening. However, my issue (described below) started happening well AFTER my CPU upgrade (ie: not right away).

I've been experiencing a SIMILAR problem with hangs/freezes when downloading a file (browsing is just fine, even with multiple tabs, etc.) in FF 2.0.0.5. I noticed a common experience in this thread that FF hangs when it opens a new window of some sort--which also happens when downloading a file--so I don't really know if this is necessarily a CSS rendering thing (just a guess--I'm no programmer).

But for some reason, I can sometimes avert the hang by quickly clicking in the original browser window right before the file dialog opens and the download is started...otherwise it hangs almost 100% of the time (and the window title bar says "Not responding" if clicked).

Actually, I figured out that my problem (huge slow down on a mega-powerful PC) is actually, because of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=235853
Firefox is unresponsive when processing (or retrieving) the automatic proxy configuration file.

I wonder if most of people who noticed this bug (266627) are actually suffering from the slow automatic proxy configuration processing. It is very easy to verify: just manually read your configuration file, figure out which proxy you are supposed to use and tell Firefox to use this proxy. If everything is fast, then you are suffering from 235853.

P.S.
This bug did not happen on my work laptop, because: 1) when using VPN all the pictures on the web page are fetched from 1-2 servers - quick PAC file processing; 2) when browsing normal internet, I disable the automatic proxy confuguration

I don't use any proxies and still have this problem.
(I have selected the option "Direct connection to internet" This is by default. I did not ever change it)

The problem also happens when loading images directly (so it it not due HTML processing; is are images rendered by gecko ?) , like http://img264.imageshack.us/img264/1815/quantumdblp7.png

I can confirm all the symptoms mentioned above, but I noticed that forefox often freezes even when opening blank new tab. Also with several tabs already opened when switching beetween tabs firefox will often freeze for few seconds.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

This problem started occuring after several month of working normally, but I can not recall was it after firefox update or some other software being installed. Tried reinstalling firefox, tried in safe mode, no help.

Firefox locks up often (many times throughout the day).

Every time Firefox does this, the Firefox.exe process is at 50% (sometimes 49%, sometimes at 51%, but the vast majority of the time, it is 50%).

I started noticing this in the early Version 2.0.
The first couple were fine (2.0), but after the 2nd or 3rd version (like 2.0.0.4), Firefox hangs most of the time.

This can happen by just clicking on another tab, without reloading any web pages and/or going to a different page.

For me, it can last minutes before Firefox starts responding again.

And, when Firefox hangs, ALL Firefox browser windows hang.
No scrolling, can't change tabs, etc.

I have about 4 Firefox windows open.
One of them only had one webpage open.
Another has about 30 tabs open.

OS: XPSP2
RAM: 4GB
Current Firefox version: 2.0.0.14

I'm thinking about uninstalling Firefox and going back to one of the earlier ones.

Comment #58: the 50% of CPU is probably because you have a dual core CPU (or hyperthreading), firefox is using 100% of one CPU and none of the other

can you try with a totally new profile? and how about not using any proxy (or a manual proxy instead of automatic if you require one)

As I already said, I hade all of the mentioned problems and _ALL_ my problems were resolved when I disabled antivirus (Symantec)!

I thought I was experiencing this bug, but in fact, I was using an old version of Fission that wasn't automatically updating, and it had a bug in it that recently raised its head, producing quite similar behavior. Once I realized that that might be it, I went to the add-on's site, and had to manually upgrade it to the newer version, and that totally fixed the problem. Clicking on links are jumping directly to pages now, no delay, so check on this people if you use Fission.

I have observed this on Windows XP as well. It also happens when I am loading a site in one tab while browsing in another one simultaneously. When it happens, I get 100% CPU usage for several seconds. I have also observed that it has only started happening since I installed the latest update - 2.0.0.14.

Correct.
I have a dual core Pentium 2.8GHz.
Only one of the cores is at 100%, the other one is basically 0%.

As for comment #60, I am using Trend Micro AntiVirus now.
I have used Norton AntiVirus (Symantec) in the past, but there has been no change as far as Firefox's hanging issue.

And, why would an AntiVirus (any brand) cause Firefox.exe to max out the CPU?

A couple of PSs to my Comment #63:

1. I had uninstalled Firefox 2.0.0.14 and re-installed Firefox 1.5.0.2.

It did not hang like Firefox 2.0.x does.

But, 1.5.0.2 does not seem to work with some sites, like
http://www.mycokerewards.com.

I re-installed 2.0.0.14.

2. I am not using "Fission".

It does NOT hang with Firefox 1.5.0.2, and it is running on the exact same system with a dual core Pentium, and the same AntiVirus.

It appears that disabling these apps is just fixing a symptom, not the core problem of this issue.

Note that antivirus programs can cause delays. Example:
dowload a large zip file.
when download reaches 99% (100% actually, but the dialog shows 99%), and firefox tries to save (and close, I guess) the file, the antivirus (NOD32 in my case) will check the archive for malware. This uses 100% CPU (in the nod32 process in this case), takes several seconds and makes the firefox download dialog frozen for that time.

I will check if the bug symptoms disappear on my system(s) after disabling the antivirus program.

I just installed Opera 9.27, opened ALL web pages that I have opened in Firefox, and Opera works fine,.....no lock up, no hanging, etc.

I have both Firefox and Opera opened at the same time with the same pages.
Firefox (2.0.0.14) hangs and Opera does not.

Firefox even hangs just clicking on a different tab, and it can last over a minute.

As noted before, Firefox 1.5 does NOT hang. This has only been an issue with early Firefox 2.x to current versions.

Even when the CPU is basically at idle, Firefox can hang and not allow the user to switch between open tabs.

It is exclusively Firefox.

If it was malware, Anti-Virus, etc., it would affect other browsers too, but doesn't, including Firefox 1.5.

Are You Frustrated With Firefox?
http://mashable.com/2008/04/30/are-you-frustrated-with-firefox/

Some quotes from the link above::
"You are right... Firefox can be very, very slow. Sometimes it uses over 500MB RAM on my machine..."

"I must say that Firefox is working better for me than Safari, it does crash about once a day."

"I don't use FF much anymore because it is so slow in comparison to other browsers"

"You are totally right. Sometimes you can't even switch/close tabs!"

"I have actually moved much of my tasks back over to IE7 due to the fact that if I leave the Firefox browser open for more than a couple of minutes it totally freezed my machine."

"With FF 2 I reached a level where it would crash at least 10 times a day. I'm working with FF3 and it's more stable but still can't handle loads of tabs open (ie, regular work)."

This has been going on since 2.0.0.4.
http://www.mozillazine.org/talkback.html?article=21921
Firefox 2.0.0.4

"This latest version of Firefox, however, is causing all sorts of hang-ups in the system."

js-777 in comment #68
> Are You Frustrated With Firefox?
> http://mashable.com/2008/04/30/are-you-frustrated-with-firefox/

js-777, these are interesting but of little practical use to this bug, and for the most part they don't even match up here - this bug goes back to version 1.0 and doesn't revolve around memory issues, hangs, etc. see 1.1 of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

As for your personal problem(s), it doesn't seem to be a good match to this bug. For starters, your problem didn't start until version 2 - clearly making it not a match for this bug. Please file a new bug so it can get some focused attention.

(In reply to comment #32)
> As aways "transfering from..." is given in the status window so the bug happens
> after DNS resolving. See previous post for exact FF behavior.
>
> Used:
> set NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5
>
>
> Here is the log:
> http://www.mcnutt.org/duncan/firefox%20bug%20266627%20log%201.txt
>
> Is there a way to add a timestamp to each log entry? That would make finding
> the place at which the error occurs easier.

Duncan and others who see the problem, this is now possible by adding ",timestamp" to the module list. Can you reproduce and create new log with ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ ? Suggest you also add dns to the module list.

If anyone who previously commented in the bug but no longer see this problem, please add a comment.

There's been no activity, nor more useful information added to this bug. I'm going to mark it RESOLVED INVALID.

For now, if you are continuing to experience performance problems, I'd suggest using the Gecko Profiler add-on, collecting a profile, sharing the profile, and then pasting a link to your uploaded profile either in this bug, or a new bug.

A link to the Gecko Profiler add-on: https://addons.mozilla.org/en-us/thunderbird/addon/gecko-profiler/