Closed Bug 72138 Opened 19 years ago Closed 19 years ago
Incremental page loading is broken
There have been reports that pages no longer load incrementally. After a long pause the entire page is displayed.
Severity: normal → major
Target Milestone: --- → mozilla0.9
Incremental page loading seems to be working. I tried created a very large document consisting of a <BODY> followed by thousands of <P> tags. After a few seconds it displayed the top portion of the document while continuing to load the rest of the document which took another (approx. 20seconds.) I also tried creating a very large document consisting of a table with thousands of rows. It also loaded incrementally. I tried running using a 28k connection and loaded www.icq.com. Mozilla loaded the top table incrementally.
The last few days, I've been seeing the following case, which may or may not be related: the page starts to load, and I see most of the content. If hyperlinks are included in the displayed content, they will light up on mouse hover (if style is set for that). Then suddenly, the entire page blanks out, and then I see the exact same content load again. During this second load, the same hyperlinks and such can't be clicked until the page is nearly finished. I *think* it's only visible with a slower connection, and it doesn't seem to happen on all sites. Could this be the problem that was reported? One site for this was gamespot.com.
we are not displaying pages as quickly as we could. In many cases the nsParser::OnDataAvailable is called multiple times (10+) without flushing any tags. This leads to sluggish display of pages, especially on slow connections. Even large local pages take up to 5 seconds before anything appears with a fast machine (750Mhz). If I change the content.notify.interval default in nsHTMLContentSink from 1 second to 1/4 second pages display their initial contents much faster. In the local page case it went from 5 seconds to less than 1 second.. The initial display of sites such as yahoo.com and icq.com with a slow connection is much faster after changing the default as well. The original content.notify.interval code was implemented by firstname.lastname@example.org The default for content.notify.interval has not changed since his original checkin for bug 17325 . The comments in the bug lead me to believe that we have not attempted to tune the default value given to content.notify.interval.
Status: NEW → ASSIGNED
You can test out the content.notify.interval change without having to apply the patch. Just add the following pref: user_pref("content.notify.interval", 250000);
jrgm's peformance tests show no degredation in performance when the pref is changed from 1 second to 1/4 second. The tests do not show a performance hit until the pref is set to 1/10 of second or below. When I check in the patch I'll add a comment explaining how the default value of determined. The only performance hit I have seen is loading large text documents. The reflows generated as the result of the content appended are very inefficient so increasing the number of reflows doubled the page load time in this case. I filed a new bug to look at this issue bug 72885.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.