44998 - Mozilla very slow on www.monitor.hr

Status: VERIFIED DUPLICATE of bug 42138

(Core :: Layout, defect, P3)

Description

[Miroslav Silovic]

Attempting to open www.monitor.hr causes the browser to hang (100% CPU usage).
I couldn't extract the stack trace.

Build: today's nightly M17 (this bug was not present in M16 and it was present
       in two week old M17, as well)

OS: Solaris 2.6

Comment 1

[Jeffrey Baker]

Wait longer :)  On my machine, this page rendered after about two minutes of
apparent death.

Comment 2

[Doron Rosenberg (IBM)]

adding helpwanted keyword, setting platform all.

we need a testcase

Comment 3

[Asa Dotzler [:asa]]

ouch, this is slow.  will try to investigate.

Comment 4

[Miroslav Silovic]

I also have to warn you that monitor.hr's network is very slow (consider
yourself lucky if you get 1kb/s, unless you're in .hr domain). You probably want
to make a local copy of the page before you test.

Comment 5

[John Dobbins]

Attachment: Monitor.hr HTML

Comment 6

[John Dobbins]

Tested build 2000071408 on win 98
Mozilla freezes every time. On one test I waited 5 minutes for slow load. Also 
tested with NC 4.73, page loaded normally. Saved to drive with NC, Mozilla 
freezes trying to load from drive. Added saved page as attachment so testing 
won't be held up by slow connection.

Comment 7

[Asa Dotzler [:asa]]

anyone want to try to simplify this and figure out what's slowing us down.  I'd
guess it's in parsing through all those unclosed font tags ( I seem to remember
a similar bug where it was unclosed tags, but this is just a guess).  adding
qawanted keyword

Comment 8

[Asa Dotzler [:asa]]

This page seems to be loading at an acceptable pace with current branch and
trunk builds 08/02 on NT and Mac.  Resolving Worksforme.

Comment 9

[Miroslav Silovic]

I retested, and it still hangs, both on www.monitor.hr and on the attachment
posted here. Build is 20000804 from nightly source snapshot, on Solaris 2.6
(I gave up after several minutes wait).

Comment 10

[Bruce Mitchener]

Pike on #mozilla confirms this hangs for him on Solaris.  Still hangs for 
Miroslav.

Comment 11

[Decklin Foster]

I'm continuing to see the hang for ~1 minute on Linux -- suggest Platform/OS be
updated.

Comment 12

[Decklin Foster]

Rechecking with CVS from 082017, speed has gone way up (but we still go up to
99% CPU for a while). Time to render page is now about 10 secs.

Comment 13

[Asa Dotzler [:asa]]

over to Layout.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Assigning to waterson, cc: buster.  This looks, based on a jprof run, like it's
going into infinite or near-infinite recursion between nsInlineFrame::Reflow,
nsInlineFrame::ReflowFrames, nsInlineFrame::ReflowInlineFrames,
nsLineLayout::ReflowFrames.

I recommend verifying that this is what you see as well, since I have some
changes near (but not in, I don't think) this code in my tree.  If you don't see
this, please let me know that it's my fault!

Comment 15

[Chris Waterson]

I took a quick look at the HTML on this page, and from the looks of it, this is 
a dup of the nested <font> tag bug 42138. cc'ing harishd.

Comment 16

[Chris Waterson]

*** This bug has been marked as a duplicate of 42138 ***

Comment 17

[Scott Brodmerkle]

Verified dupe.