Jacob Kjome Reporter
	Description • 24 years ago

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

	Luis Villa
	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.

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 2 • 24 years ago

Triage

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 3 • 24 years ago

Changing crasher bug milestone to mozilla0.9.

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 4 • 24 years ago

Nisheeth, this is a potential dupe of bug 57451.

	Nisheeth Ranjan
	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.

	karnaze (gone)
	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.

	Chris Waterson Assignee
	Comment 7 • 24 years ago

I can take a look...

	Chris Waterson Assignee
	Comment 8 • 24 years ago

Just profiled this: as karnaze notes, 64% of the time is spent in 163 calls to
nsCSSFrameConstructor::ReframeContainingBlock().

	Chris Waterson Assignee
	Comment 9 • 24 years ago

End-of-milestone reality check.

	Christian Mattar
	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

	Chris Waterson 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.

	Marc Attinasi
	Comment 13 • 24 years ago

The patch look good Chris: [s]r=attinasi if you want/need it.

	karnaze (gone)
	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).

	Chris Waterson Assignee
	Comment 15 • 24 years ago

Will do. I'll make some regression tests right now to stress this code.

	Hixie (not reading bugmail)
	Comment 18 • 24 years ago

Er, Waterson? You seem to have forgotten the definitions of "do_append()" in
those tests...

	Chris Waterson 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.

	Chris Waterson Assignee
	Comment 20 • 24 years ago

Allright, fix is in, a=chofmann.

	Ronald van Kuijk
	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?

	Chris Waterson 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...)

	Chris Petersen
	Comment 23 • 24 years ago

Marking verified per last comments.

	Ronald van Kuijk
	Comment 24 • 24 years ago

Bug 83721 filed on shift-reload 'problem'