When loading some long pages, Mozilla displays nothing until the entire page is done rendering. During this time, the throbber stops, and I cannot interact with other Mozilla windows. Depending on the length of the page, Mozilla may effectively be frozen, and I have no way to close the problematic window. Incremental rendering is necessary for making the browser fast in a useful way, whether the limiting factor is bandwidth or CPU time. Mozilla currently does a good job of incremental rendering for slow pages, but it does *worse* when the same page is loaded over a fast connection. I believe this is a regression. Examples: 1. http://slashdot.org/article.pl?sid=02/03/07/2132243&mode=thread&light=1 Incremental rendering at Slashdot used to work very well in Mozilla. It used to be that Mozilla was the only browser that would display slashdot comments as the page loaded (although this only worked in light mode). IE only displays the article as the comments load (again, only in light mode). Because of this regression, IE's incremental rendering now beats ours. 2. http://bugzilla.mozilla.org/buglist.cgi?email2=jrud&emailreporter2=1 Loading a 800-bug list (ALL reporter:jrud) sometimes hangs Mozilla for a few seconds, and a 2000-bug list (UNCO) sometimes hangs Mozilla for more than a few seconds. I think the sometimes depends on Bugzilla's load. When Mozilla doesn't hang, it displays the bug list one or several bugs at a time, which is great. 3. view-source:http://www.w3.org/TR/REC-html32 (see bug 129612) For view-source, note that view-source:http://mpt.phrasewise.com/ *does* render incrementally, since mpt.phrasewise.com loads slowly. This case may not be a regression.

Forgot to mention: that's 2002 030604 on Windows 98.

reporter: Any idea on when the regression started? Do you know of an earlier build that was working ok?

Taking

Changing Priority to P2.

Tested with a slashdot story, clearing the cache after launching each build: broken: (2000 december) mozilla 0.6 broken: (2001 050515) mozilla 0.9 broken: (2001 080110) mozilla 0.9.3 broken: 2001 101803 broken: 2001 120703 broken: 2002 012708 broken: 2002 020703 broken: 2002 030803 mozilla 0.9.9+ trunk Ok, so this isn't a regression in Mozilla. Slashdot or my Internet connection must have become faster. Still, this bug makes it less pleasant to read Slashdot. By the way, the same several-second freeze happens if I load a copy of the same Slashdot story from my hard disk.

Loading an 8mb HTML file from disk does this every time. Loading view source on a 3mb HTML file will have the same exact effect (disk is irrelevant at that point, since view source comes from cache).

Moving to P1. I believe this bug is the result of event starvation caused by the reflow PL_Events being processed at a higher priority than the paint and other events. Any fix for this would probably require changing the order in which we process events or how we schedule reflow events. A fix for this would be risky in the Mozilla1.0 timeframe.

Reporter, Are you still able to reproduce this in the current build ?

nsbeta1+.

This was fixed by checkin for bug 157144

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html