Closed Bug 91643 Opened 23 years ago Closed 6 years ago

All Mozilla windows frozen during some stages of loading a page

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bruppel1, Unassigned)

References

Details

(Keywords: topperf) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010719
BuildID:    2001071903

For some reason this has become more apparent to me since July in nightly
builds.  It is more visible on slower machines (I am on a celeron 550) and
becomes a bigger and bigger nuisance with the more windows you have open (~11 or
so), but it is still visible with 2 or 3 browser windows.
The problem is, every time a new page is loaded, the browser stops twice during
the process, and the entire app is frozen for that time.  

When a url is entered, the throbber will start, then the entire application
(meaning all mozilla windows) will become unresponsive briefly.  The best way to
see this is to click on the title bar and try dragging the window around during
the entire page load process.  Then it becomes unstuck again, then sticks a
second time, then finishes the page.  
On some pages with faster machines, this isn't so bad.  However, many many many
pages have this problem (even bugzilla bug pages--so it's not flash or
anything).  Note also that it's really more apparent with a bunch of browser
windows open.  Also, I have a very fast connection so this problem might not
show up on slower connections.  I tried clearing my caches to see if that was a
cause, but it doesn't seem so.

Reproducible: Sometimes
Steps to Reproduce:
1.open a bunch of browser windows with assorted pages loaded
2.go to a new page in one window, and immediately click on the top title bar of
the window and drag it around constantly


Actual Results:  you should notice that the window stops moving (along with the
throbber not throbbing and the rest of mozilla being frozen) exactly twice
during the load process

Expected Results:  the entire app shouldn't freeze because of rendering or file
access or whatever is going on.
I've seen this too.  A good way to reproduce is to pull up a large bugzilla
query (eg a list of all unconfirmed bugs).

Over to layout for a start.
Assignee: asa → karnaze
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: perf
OS: Windows 2000 → All
QA Contact: doronr → petersen
Since last 3 days, bugzilla has giving me crappy response times

i don't see "stuttering" on Linux, apart from on pages with flash or java: those
have started freezing the whole interface till applet or whatever is loaded.
Page doesn't continue to load till after the plugin is "finished". It didn't use
to behave like that - or the plugins used to load way quicker.
Francisco: I see that too, but I think that's a bugzilla problem.

R.K.Aa:  I know what you mean about the java and flash pages, I see that in
win32 also.  However, this happens on even plain old bugzilla pages, which don't
use either (as far as I know).  It could, however, be a symptom of some
universal problem that's also causing this bug.
Overall i think mozilla stutters because it eats too much ram and it's somewhat slow
I dont think this will get fixed
Also see bug 49141
Francisco, I have 640M of RAM.  Mozilla is nowhere close to using all (or even
half) of it.  That's not the problem I'm seeing.  This also has nothing to do
with new window performance.  It has to do with a complete lack of screen
refreshes (freezing chatzilla, mail, and all browser windows) at the end of a
page layout.
I get it always on www.iht.com - though that may be the javascript parts. I use
a Celeron 300, 64mb ram, NT4SP6. It shouldn't be VM because I don't hear that
much disk acces. The whole thing just freezes. Pulling up another Mozilla window
doesn't work. Other programs may be somewhat affected but not grossly.

It is odd because IHT is the worse page by far. Others can have it for less than
half a second, but this one takes two or three at least.

I'm also seeing similar 'stuttering' on linux. The machine has
enough ram.
Hey, could people who see this problem please post their machine specs (OS, RAM,
CPU speed).  From a newsgroup, I just talked to a user with an 800 mhz Duron
with 512 megs of RAM and win2k who doesn't get this.

I suspect that there may be something besides hardware specs that is causing
this to be worse for some than others.

Okay, I have found that renaming my panacea.dat file has greatly reduced this
stuttering problem as reported.  (note I suggest renaming it so that one could
put it back in case there was data loss).  In fact, just about every operation
in Mozilla, from opening a message to loading a new page, is about 50% faster
now that I have renamed panacea.dat.  Perhaps this would help out people on the
cc list.

In any case, mozilla still stutters some when it loads pages, so I wouldn't call
this a resolved bug.  More importantly, I wonder how my panacea file got out of
hand as such so as to cause such serious performance problems.  Joe Sixpack
probably wouldn't think to delete this file, he'd probably just think mozilla
was slow.

Comparing panacea.dat files, I can note that the older file is about three times
as large as the newly generated one.  It contains references to long since
removed newsgroups and a host of references to friends' names
(ie:    =F:\\DOCUMENTS AND SETTINGS\\SLATE\\APPLICATION DATA\\Mozilla\\Users50\\de\
fault\\ImapMail\\imap.goto.com\\friends.sbd\\jeff.msf)(34F7=friends/jeff)
  (34F8)

There is also a lot more garbage at the end of the file (it's a bunch of stuff
that looks like this: [115(^82^7BF9)).  If renaming panacea.dat improves
performance, perhaps some of the others on this list should see if their old
file is the same way.  Then we could perhaps file a bug on it.

Reproduced on 2001083008 build, Mac OS 9.1, iMac 450 MHz, 64 MB RAM. The UI
freezes firstly before the initial layout of the page (the window title changes
during the middle of this freeze), and secondly during the final layout. An easy
way of seeing the freezes is to watch the throbber, or to move the cursor back
and forth along the Personal Toolbar.

I think that if piecemeal speed improvements each get dealt with in their own
bugs, this bug is a dup of bug 40848.
Hardware: PC → All
Hey mpt, what you describe is exactly what was happening on my win32 box.  As I 
posted, deleting panacea.dat in my profile dir obliterated the freeze and made 
a bunch of other operations at least twice as fast.  Does this work for you?  
If so, perhaps this bug should directly apply to the fact that something can go 
wrong with panacea.dat that causes such horrible performance problems.
Hi, I'd just like to say that I just talked to someone else in the newsgroups,
and apparently deleting panacea.dat worked for him.  Strange, because I kept my
old panacea file, and when I restored it, the performance problems didn't return.
Reassigning to dbaron.
Assignee: karnaze → dbaron
I think I should get a word better than "stutter" in the description.  While I
find it the best description, it's not very searchable.  Suggestions?
There are two root causes for the problems here, I think:

 1. We run all windows on a single thread.  Only networking, timers, and a few
other miscellaneous things operate on other threads.  Changing this model would
be a major change, require large amounts of work, and in general would probably
trade a bit of performance (how much?) for the non-interference between
different Windows.

 2. When loading pages we batch changes, primarily based on timers in the
content sink, sacrificing responsiveness to avoid the performance problems with
the O(N^2) nature of some parts (fewer, recently)  of incremental reflow and
incremental frame construction.  Last summer kmcclusk did some work in the
parser to prevent the parser from sending too much data to the content sink at
once, but I think that doesn't really solve the problem since the primary
batching of changes is in the content sink, downstream from the parser.  The
eventual solution to this problem is, I hope, the eventual removal of *all* of
the timers in the content sink and parser, replaced by just allowing content to
be processed as it arrives.  (However, if we do this, we would still want to
keep the paint suppression timers and we would want to ensure that when multiple
network packets are received during a single incremental layout pass, they would
be sent to layout together rather than in pieces.)

I think a realistic approach to solving this problem would be to try to fix the
second of the problems above, and this is one of the reasons I've been working
on trying to remove O(N^2) problems from reflow and frame construction over the
past few months.  At some point we need to try the experiment of removing the
timers and testing what our performance looks like without them.

That said, I'm heading back to school after a semester off and I'm unlikely to
have much time to work on this in the near future.
Severity: critical → major
Priority: -- → P1
Summary: Mozilla stutters when loading pages → All Mozilla windows frozen during some stages of loading a page
That approach sounds very promising - any news in the meantime?
Blocks: 71668
Could problem 1 in comment 16 be the cause of the problem described in bug
152171? If so, solving problem 1 would be a major improvement for gui
responsiveness. Mozilla tends to get rather choppy when opening multiple tabs at
the same time or when there is some plugin using up all the cpu time.
Think this problem is completely unrelated to the usage of multiple processors -
it's affecting the "average usecase".
IMHO related is not right word. Of course SMP is not the cause of the problem.
Single cpu systems also suffer from it but the problem is *very* visible on a
SMP box with many windows/tabs open.  Single threaded applications always make
me feel as if I have a Ferrari and am forced to drive a B road. Moz is just not
using my system to its full potential.

Although solving a O(N^2) problem is always good for performance, it will not
solve the problem this bug describes. Opening multiple tabs at once with some
large documents will still freeze all windows. Flash plugins (they seem to run
on that same thread) that use up all cpu time are also causing the problem this
bug describes: stuttering in responsiveness. This behaviour can be reproduced as
described in bug 152171.

Reflow is not interruptible; the final freeze is usually caused by the final
reflow pass, especially on complex pages.  Other freezes may be caused by
receiving a bunch of data for parsing/etc (as per dbaron's comment).
So this is bug 67752, basically...
Depends on: ireflow
Although not directly relevant to this bug I notice that the problem is
particularly noticable when loading lots of tabs (e.g. via a groupmark)
as Mozilla freezes as it reflows all the tabs when I would have thought
it would be pointless reflowing the inactive tabs until they are shown.
Keywords: perf → mozilla1.2, topperf
*** Bug 159824 has been marked as a duplicate of this bug. ***
Does this bug differ from bug 76495?
So mozilla is not multithread on document rendering[comment #16] and the 
final reflow is not interruptable, take long time[#21], how about spawn
a new thread to do the final reflow? How feasible is it? I don't think the
2nd problem in comment #16 will fix the final reflow thing which is really
anonying: when you are loading a large page, suddenly, everything become blank
because mozilla cannot redraw the screen.

Also a lot of tables does make the problem more standout. #23


> how about spawn a new thread to do the final reflow? How feasible is it?

It requires making layout threadsafe... if we do that we may as well just do
each window on a separate thread.


For the final reflow, I thought that no more data is coming in, no more timer
kicks in. Maybe that will make the thread safty easier. 

Well, the renderer is not interruptable, nor thread safe. hmm... It seems either
one of the situation need to be changed in the future. A faster render can never
be fast enough when pages get more and more complex.

Before that, this bug might be alleviated by cleanup the event queue inside
the renderer? What's the mechanism of event queue in the main thread?

You might be interested in bug 157144.
Thanks for the pointer to bug #157144. Very nice reading.

In the comment #12 in #157144, Kevin McCluskey talked about
NS_HandleEmbeddingEvent(msg, wasHandled) in the embed API. 
This handler does look like something can be called periodically 
during a reflow. Or has it already been called but did not help in 
this situation?
> This handler does look like something can be called periodically 
> during a reflow.

That would be kinda bad, since events in that handler could trigger reflows...
then you have nested reflows... and reflow, in addition to being
single-threaded, is not reentrant.  See the bug on the image blocking dialog
(the one in which the dialog was disabled) for discussion on that and the
crashes that result if you re-enter reflow.
Blocks: 167039, 168157
Depends on: 94587
Blocks: 91351
Can we retest this now that bug 157144 and bug 164931 have been checked in?

I have to say, that according to my opinion freezing of mozilla does not happen
in mozilla 1.0 but it does a lot in 1.1. At least not so offen and for so long.
Especialy it is noticable on big uncached pages or slow servers. I do not think
it is caused by JS, flash or so..
This is mainly because of O(N^2) problems from reflow and frame construction - 
just see depending bugs.

Are the particular performance issues you notice because of O(N^2) algorithms?
reporter/others can you try setting the pref:

"content.notify.interval" to 1000

Note: the current default is 120000.

This pref controls how long Mozilla will be allowed to be away from the message
loop during page load when there isn't any user interaction. The 1000
corresponds to setting we use when there is ongoing user interaction. (i.e mouse
and key events.). If this solves this issue we may need to tune the current
120000 setting. Using 1000 all the time will probably impact page load. The
120000 was determined through testing on various machines to be a value that did
not impact page load times, but that was about 1 year ago and lots performance
improvements have been done, so we may be able to lower this value.
Hmmm. This bug should be fixed by my patch in
http://bugzilla.mozilla.org/show_bug.cgi?id=165039.
Depends on: 165039
As the reporter, I feel compelled to respond:  sadly I have upgraded my computer
and am no longer able to discern the freezing very well.  others with slower
cpu's will have to check it out ;)
Re comment #36:
Using 1.2a (2002091016)
I changed the setting and I believe this *does* make a positive difference.
Because of workload I could not make comparing measurements, but I have not
seen the freezing effect since. One example where I believe the freeze was 
happening is the one-page version of the mySQL manual. No problem any
more. I dont know what the degradation of page load time is, but I did not
notice any. 
change:
"content.notify.interval" to 1000
This does make loading more responsive (just what I feel).
but it makes no different on final render on my box. Go to a large slashdot page,
use the flag mode or nested mode. When the page is fully loaded, use ctrl-+
to zoom in. There will be a several seconds freeze on Mozilla. The period might
be shorted since a few days ago, but it is still there.

We still need either interruptable render or threading render. Simply improve
the render speed is not enough. Web pages can only because more and more complex.

About Handling_EmbedEvents(), I saw that in another bug report, that rendering
is caused by a render event or reflow event. Maybe that event can be filtered
out for the current webpage. Then we have no nested problem. Or maybe I am
talking nonsense...

I see no interruptable or threading render in the near future. But this bug
is real. Since we have tabbed view, people will more likely to open pages in a
background tab, if they think the pages will take long time to load. I do.
Beside, the cc list is longer and longer.
Kevin's comment in #36 about reevaluating this value sounds very reasonable to me.
Keywords: mozilla1.2 → mozilla1.3
There is no need to reevaluate this value. Gecko dynamically switches to use the
lower 1000 value now that fixes for the following bugs have been checked in

http://bugzilla.mozilla.org/show_bug.cgi?id=165039
http://bugzilla.mozilla.org/show_bug.cgi?id=157144
the original description of this bug should be fixed on WIN32 by the fixes for
the bugs I mention in the previous comment.

The reflow/paint lag when increasing/decreasing the font size is a separate
issue. FYI: on winxp, 750Mhz AMD. IE 6.0 is also unresponsive when changing the
text size. Opera 6.0 remains responsive to user input, but it blanks the window
while resizing the fonts and takes much longer than Mozilla/IE to complete the
resize operation. I tested this by loading www.slashdot.org and
increasing/decreasing the font size and attempted to interact with menus/scrollbar.
I've tried the 2002112121 build. Page load does feels a lot smoother.
I still see short freeze on pages with many tables on my duel
celeron 500Mhz 196MB RAM box. But the freeze is less than 2 seconds,
maybe just 1 seconds, so I have no complain anymore. Not now. 
Thanks.

Since there are still short freeze, I am wondering how mozilla hold on 
more complex pages in the future. Is the freeze always a constant time
or become longer when pages get more complex.

test page: http://cuiweiju.xilubbs.com (Chinese page).
That might be completely smooth once bug 94587 is fixed - right?
Flags: blocking1.4?
Keywords: mozilla1.3 → nsbeta1
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Blocks: 203448
Flags: blocking1.4? → blocking1.4-
Changing qa contact to madhur since I'm no longer in layout and not sure  which QA contact 
person should get this ..
QA Contact: cpetersen0953 → madhur
S.Gupta & M.Rattan, 02/23/04) Conformation of bug with a variant (follow up
test) example

Successfully able to replicate the bug on Windows XP Professional, with
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.6) Gecko/20040206
Firefox/0.8"

Steps for replication (a variant of the bug):

Step1 - Open the following URL in a few browser windows say 3-5 (for a simple
demo 2  will do) http://www.romanm.ch/ascii-movies/ascii-spiderman1.htm

Step2 - On this page, change the size of animation to "1px" from a drop down
list at the top of the page (this will help in a clearer view of the bug).

Step3 - Resize the windows to a size such that you can see all the animations
simultaneously.

Step4 - move the mouse to any one of the browser's "title bar" and press "left
click". (you will see that not only the animation in that window freezes, but so
do the ones in other browser windows!)

Step5 - move the mouse to any one of the browser's "title bar" and press "right
click". (you will see that not only the animation in that window freezes, but so
do the ones in other browser windows!)

Step6 - While the animation is playing, go to "File" menu and click on "Open
File" item. The "Open File" dialog opens and the animation freezes in all the
browser windows. (Even reloading the other browser page/url does not allow the
animation to proceed normally)

Step7 - While animation is playing, go to "File" menu and click on "Save Page
As" item. The "Save Page As" dialog box opens and the animation freezes in all
the browser windows. (Even reloading the other browser page/url does not allow
the animation to proceed normally)

*The same test runs perfectly on I.E. and with little lag/latency/freezing on Opera.


Follow up tests:
1.Replicate on different Operating Systems (as discussed and performed in the   
  additional comments of the bug report already existing).
2.Replicate the bug on different browsers to check whether it is just a feature 
  or actually a bug (*works fine with I.E. and Opera).
3.Replicate the bug using animations rather than just static pages (in what we 
  did, the animation froze and gave a better view of the bug).
4.Vary the program settings or try to see if the bug is related to any other 
  function, or behaves in certain different manner with some other browser 
  functionality (as in case of the “open file” and “save page as” options 
  discussed above).


Importance of the bug:
1.As stated earlier, the other contemporary browsers (in which the bug was 
  replicated), do not misbehave rather allow the animation to run just fine. 
  This could be a critical point which the users notice and opt for other 
  browsers.
2.This behavior can freeze animations, online games (not tested), which can be 
  much undesirable by users who work heavily with such applications. 
3.This bug certainly restricts working with/in other browser windows. A user 
  certainly would not want to be restricted by such a bug, not allowing other 
  applications (in the browser windows) to function properly.

These issues depict that the bug certainly restricts usage of other browser
windows in case such a condition occurs with any of one of them. This seems to
be a potential case which can affect the usage and thereby the integrity of the
browser on the longer run.

*** Bug 238097 has been marked as a duplicate of this bug. ***
You can also see what happens fairly clearly in
http://www.kuro5hin.org/story/2003/8/25/81349/5640
On my AMD X2 4200+, i get this annoying behaviour quite often. I always experience this total UI freeze when restoring a session (i mean starting firefox and restoring, i.e loading many tabs). The freeze is especially long when the network is loaded (eg: DSL overloaded because of P2P)

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
This bug is reproduced on my machine, quite often.
Sometimes to make it worse, the browser becomes completely freezed.

Windows XP JP SP2
 Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

as well as and other version of FF 2.0.0.4, 2.0.0.5, 2.0.0.2, 2.0.0.1
Flags: wanted1.9.2?
QA Contact: madhur → layout
bug 501158 belongs here 
(URL:http://www.ynet.co.il/articles/0,7340,L-3465625,00.html  Firefox freezes for several seconds during page load ) 
I think this should be marked as depends on bug 501158 .
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-
This bug isn't reproducible in Firefox 7.
I think it can be marked as fixed.
Marco - please indicate what tests you did and on what machine.  Current machines are perhaps 50+ times faster than when this bug was reported; that doesn't mean the bug isn't still there.

It may be (largely) fixed; and per bz's comment 27 (from 2002), creating a per-tab thread (aka Electrolysis, more-or-less) will help avoid hitting the rest of the browser and UI.
The links of the tests in the comments are broken.
I've tried the link from comment 53, and there isn't any issue.

My machine is quite fast, so I've tried the same test in my netbook (Intel Atom 1,6 GHz) and the bug isn't reproducible (the browser UI isn't so responsive, but there isn't any window frozen).
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.