If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

{ib} large page takes minutes to load and locks up browser

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Layout
P3
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Jacob Kjome, Assigned: Chris Waterson)

Tracking

({hang, perf})

Trunk
mozilla0.9.2
x86
All
hang, perf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 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

Comment 1

17 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

17 years ago
Severity: normal → critical
Keywords: crash, perf
Changing crasher bug milestone to mozilla0.9.
Target Milestone: --- → mozilla0.9

Updated

17 years ago
Keywords: crash → freeze

Updated

17 years ago
Keywords: freeze → hang
Nisheeth, this is a potential dupe of bug 57451.
Assignee: joki → nisheeth

Comment 5

17 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

17 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 7

17 years ago
I can take a look...
Assignee: buster → waterson
(Assignee)

Comment 8

17 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

17 years ago
End-of-milestone reality check.
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

17 years ago
Blocks: 77421

Comment 10

17 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

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Assignee)

Comment 11

17 years ago
Created attachment 36461 [details] [diff] [review]
optimize ContentAppended() to avoid reframe when possible
(Assignee)

Comment 12

17 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

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

Comment 14

17 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

17 years ago
Will do. I'll make some regression tests right now to stress this code.
(Assignee)

Comment 16

17 years ago
Created attachment 36611 [details]
test case that stresses fast-case logic
(Assignee)

Comment 17

17 years ago
Created attachment 36612 [details]
test case that stresses |ReframeContaingBlock()| case
Er, Waterson? You seem to have forgotten the definitions of "do_append()" in
those tests...
(Assignee)

Comment 19

17 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

17 years ago
Allright, fix is in, a=chofmann.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 21

17 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

17 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 23

17 years ago
Marking verified per last comments.
Status: RESOLVED → VERIFIED

Comment 24

17 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.