Closed
Bug 58674
Opened 24 years ago
Closed 24 years ago
{ib} large page takes minutes to load and locks up browser
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: jrspm, Assigned: waterson)
References
()
Details
(Keywords: hang, perf)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details |
Tested on Mozilla MTrunk build 2000103104 Loading this page: http://docs.iplanet.com/docs/manuals/ias/60/JavaProgGuide/jpgdeplo.htm#11284 Takes forever to load. Symptoms: Blank page for up to 2 minutes and all open Mozilla browsers are locked up. It then finally loads. I had a report from one user on #mozillazine who said that it loaded, but just flashed the content and disappeared. I did not see that, but I can believe it based on this strange behavior. To Reproduce: 1. Open said link in Mozilla 2. Wait and/or try to view other mozilla windows or move the current window. You will have no such luck 3. After 1 - 2 minutes, the page should display and mozilla will cease to be locked up Jake
Comment 1•24 years ago
|
||
Yeah, I'm seeing that same behavior under Linux with a PIII 933 and 128 Mb RAM. Definitely an issue. Marking confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Triage
Assignee: clayton → joki
Updated•24 years ago
|
Changing crasher bug milestone to mozilla0.9.
Target Milestone: --- → mozilla0.9
Updated•24 years ago
|
Updated•24 years ago
|
Nisheeth, this is a potential dupe of bug 57451.
Assignee: joki → nisheeth
Comment 5•24 years ago
|
||
The performance on this page was significantly worse than the performance on the page linked from bug 57451. So, I am not marking this bug as a dup of 57451. This bug belongs to the layout camp. Re-assigning to Chris Karnaze, the layout manager.
Assignee: nisheeth → karnaze
Comment 6•24 years ago
|
||
nsCSSFrameConstructor::ReframeContainingBlock is getting called too many times, and I suspect that this is the problem. nsCSSFrameConstructor::WipeContainingBlock gets called also. Reassigning to Buster.
Assignee: karnaze → buster
Assignee | ||
Comment 8•24 years ago
|
||
Just profiled this: as karnaze notes, 64% of the time is spent in 163 calls to nsCSSFrameConstructor::ReframeContainingBlock().
Status: NEW → ASSIGNED
Summary: large page takes minutes to load and locks up browser → {ib} large page takes minutes to load and locks up browser
Assignee | ||
Comment 9•24 years ago
|
||
End-of-milestone reality check.
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 10•24 years ago
|
||
Another page which loads very slowly is http://www.warcraftiii.net. I'm not sure if this is another bug, but I made an interesting observation: Wait until the page loads, then scroll it with the scrollthumb. It seems that the further down you scroll, the slower it gets. If you scroll back up, performance becomes better again. There's no visible difference in the page layout, though. Please note that both the HTML in iplanet as well as in warcraftiii.net is a huge mess. The W3C validator gives lots of error about wrongly nested tags. Perhaps the parser gets confused and creates a broken tree. I'll try to fix the HTML, so that we can see if it makes a difference
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
Okay, this particular page (iplanet docs) ended up not being too hard to deal with. It turns out that most of the time (all of the time, on this page), we're appending to the anonymous block that gets created when an inline frame is split. When that is the case, we can just let the normal frame construction logic do its magic. The basic idea is to - check if the parent frame is ``special'' (that is, it's an inline frame that's been split into inlines surrounding a block) - advance to the parent's last ``special'' sibling (since we're appending, we know this is where the new frames must be added) - if the last sibling is the anonymous block frame, then we can go ahead and use the normal frame construction logic. If not, then reframe. (Note that ConstructInline() and SplitToContainingBlock() only create a ``trailing'' inline frame if there are actually child frames that need to live there.) The above patch drops the page load time from 24s on my machine to l.t. 2s.
Keywords: patch
Comment 13•24 years ago
|
||
The patch look good Chris: [s]r=attinasi if you want/need it.
Comment 14•24 years ago
|
||
r=karnaze, assumming all regression tests pass. Chris, I'm not sure how many block tests actually cause frames to be split, but if there aren't very many, you might consider adding a few (just a suggestion).
Assignee | ||
Comment 15•24 years ago
|
||
Will do. I'll make some regression tests right now to stress this code.
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
Er, Waterson? You seem to have forgotten the definitions of "do_append()" in those tests...
Assignee | ||
Comment 19•24 years ago
|
||
Oh, heh. It's vestigial. I'll nuke it. It turns out that the DOM calls always end up calling ContentInserted(), so I needed to do some tomfoolery with document.write() to get ContentAppended() to be called at the right times.
Assignee | ||
Comment 20•24 years ago
|
||
Allright, fix is in, a=chofmann.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 21•24 years ago
|
||
Great, realy greay improvement. More than a 1000% win from 250s. to 23s on an initial (clear cache) load. Still some inprovement (probably other bugs) cause ns4.7x only takes 12s. Still a great improvement. One question however. Why does it take almost twice as long (39s) when I do a shift-reload? There does not seem to be a bug on this. Should I file one?
Assignee | ||
Comment 22•24 years ago
|
||
Yes, please do file a bug. Also, it would be interesting to know how long it takes to load a very simple page (e.g. google) after loading this test case. (In other words, is the teardown of the document what's expensive...)
Comment 24•24 years ago
|
||
Bug 83721 filed on shift-reload 'problem'
You need to log in
before you can comment on or make changes to this bug.
Description
•