Closed Bug 91643 Opened 19 years ago Closed 2 years ago
All Mozilla windows frozen during some stages of loading a page
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
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'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?
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).
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.
*** 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.
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.
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.
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?
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:22.214.171.124) Gecko/20070309 Firefox/126.96.36.199
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:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206 as well as and other version of FF 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199
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 .
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: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.