50634 - CNN locks up 450MHz G4 for 4 seconds

Status: VERIFIED DUPLICATE of bug 39368

(Core :: Layout, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

type "www.cnn.com" into the url bar. from the time that I hit enter, my menubar 
clock freezes and doesn't continue ticking until 4-5 seconds later. The entire 
machine is taken over (can't use mozilla or any other app) while it finishes 
loading and laying out the entire page in one fell swoop. This used to be much 
more incremental.

obviously, I don't know what the exact problem is yet, but we need a placeholder 
for the lockout of user interaction while webpages are loading so we decided 
today in macdev to file a bug on it. CNN is a high profile page to lock up the 
machine on, being in the top100.

Comment 1

[Mike Pinkerton (not reading bugmail)]

adding keywords (esp nsmac1). obviously clayton shouldn't own this. who should?

Comment 2

[Simon Fraser [no longer active]]

Over to waterson, to fiddle with teh backup count. He sez:
The only thing that I can think of is that I set the default value for the
"back-off count" (which is really the "shut-off count") to "-1".

You can try changing this value in your preferences...

  user_pref("content.notify.backoffcount", 3);

...to see if the problem "goes away". (What this means is that after three
reflows, the content sink will no longer trigger reflow at all; we'll wait until
the document has completed loading.)

Comment 3

[Simon Fraser [no longer active]]

adding nisheeth

Comment 4

[Simon Fraser [no longer active]]

Adding dependency on 49874 (although it's not clear that this is the root of the 
problem)

Comment 5

[Chris Waterson]

So did you try that simon? Did it fix the problem?

Comment 6

[Simon Fraser [no longer active]]

Setting the "content.notify.backoffcount" pref to 3 does not seem to make any 
difference.

Comment 7

[Chris Waterson]

platform -> all. juicy.

Comment 8

[Mike Pinkerton (not reading bugmail)]

FWIW, http://www.cnn.com/SHOWBIZ/ locks up my G4 450 for over 15 seconds (mind
you, that's a debug build, but still!)

Comment 9

[Chris Waterson]

pinkerton: could you re-test? I think that jst & vidur got to the bottom of this
problem; it had to do with event ordering.

Comment 10

[Mike Pinkerton (not reading bugmail)]

waterson, when did these fixes land? my debug builds from 9/11/00 (afternoon-ish) 
still lock up for 9 seconds on CNN.

Comment 11

[Edward Kandrot]

http://www.ebworld.com/ebx/editorial/reviews/reviews.asp?pf_id=179722 locks up
for around 30 seconds on a P3 733 running Linux and under Windows as well.  This
is a site where users write reviews of games, where all of them seem to do this.

Locks up much worse than any of the others listed in this bug report, from what
I can see.

Comment 12

[Mike Pinkerton (not reading bugmail)]

my last statment should be fed to the dogs, i just realized i'm building with 
profiling on. sorry!

Comment 13

[Simon Fraser [no longer active]]

From my readings of the bug that vidur and jst were working on (bug 36849), their 
changes only affected Windows. Is that true?

Comment 14

[Chris Waterson]

Just did a profile of edward's page
(http://www.ebworld.com/ebx/editorial/reviews/reviews.asp?pf_id=179722) in
viewer. The problem appears to be that we're forcing the big table cells that
contain a ton of content to reflow every time we get new content appended to
them. PresShell::ContentInserted() is calling DidCauseReflow(), which calls
PresShell::FlushPendingNotifications() and forces all pending reflows to be
immediately processed. This happens about 330 times while the document loads,
and eventually fans out to over 200,000 line reflows :-(.

Removing the call to PresShell::FlushPendingNotifications() allowed the page to
load almost instantaneously, but I'm not sure what that will break.

nisheeth: this looks like your area...would you like to take a look?

  

Comment 15

[Chris Waterson]

Based on above data and 

  news://news.mozilla.org/39BEEC54.781710CE%40netscape.com,

it looks like you've got this one nailed, nisheeth...

Comment 16

[Nisheeth Ranjan]

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

Comment 17

[Chris Petersen]

Marking verified dup of 39368.