100359 - Browser freezes on IBM DB2 SQL Reference web page

Status: RESOLVED DUPLICATE of bug 109181

(Core :: Layout, defect)

Description

[Fred Hesby]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001091303

Mozilla 0.9.4 now freezes on an IBM web page that used to display just fine in 
0.9.3

No error dialogs appear, and the browser is irrevocably frozen. My only option 
at this point is to close down that instance of Mozilla, either through Win2K 
task manager, clicking the browsers upper right "X" button on its window frame, 
or by right-clicking on the Mozilla task bar tile, which allows me to close the 
program (after displaying the "...this program has stopped responding..." dialog

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla 0.9.4 or use an existing open browser window. It doesn't make a 
difference
2. Enter the following URL: 
http://www-4.ibm.com/cgi-
bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?
fn=db2v7s0frm3toc.htm
3. Hit Enter

Actual Results:  The page starts loading, but it quickly stops. The throbber, 
and everything else in the broweser freezes. The browser does not repaint 
itself and it cannot be moved. Alt-tabbing to the frozen window

Expected Results:  Loaded the page

No additional information available, since it is a hang, not a crash

Comment 1

[Tim Powell]

Confirmed. Hangs on 20001091703 nightly Win2K. Changing summary because Mozilla
!= Netscape.

Comment 2

[Tim Powell]

Attachment: Simplified version of page that eventually loads

Comment 3

[Tim Powell]

In trying to find the problem, I created the simplified page that I just
attached. It loads, although somewhat slowly. I'm not sure what to think of the
duplicated content. It does not render this way in IE5.5. This duplication may
just be a nested table problem, although I don't think so.

This page consists of 868 named links. Each link looks something like this:

<BR><img
src="/software/data/db2/udb/winos2unix/support/doc_gifs/vr7/squaresm.gif"
hspace=4><A NAME="ToC_275"
HREF="/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2v7s0concap.htm#Header_275">Floating-Point
Operands</A>

I'm not sure why this page would cause the hang, but I see two possibilities. 

1) Notice that every link is preceeded by the same image. I seem to recall a bug
that Mozilla requests every image whether or not it is in cache or a duplicate.
Don't know if it was fixed or only occurs in certain situations. I did a test
where I removed all the squaresm.gif images from the HTML and it didn't seem to
help. 2) There may also be a problem with creating this many named anchors.
Anyone see any other possible causes?

Comment 4

[sairuh (rarely reading bugmail)]

layout? parser? don't think this belongs in xp apps.

Comment 5

[Marc Attinasi]

The problem is that we are repeatedly reframing the containing block. See this
code from CSSFrameConstructor, which we are repeatedly hitting:

  if (IsFrameSpecial(parentFrame)) {
    // We are pretty harsh here (and definitely not optimal) -- we
    // wipe out the entire containing block and recreate it from
    // scratch. The reason is that because we know that a special
    // inline frame has propogated some of its children upward to be
    // children of the block and that those frames may need to move
    // around. This logic guarantees a correct answer.
#ifdef DEBUG
    if (gNoisyContentUpdates) {
      printf("nsCSSFrameConstructor::ContentInserted: parentFrame=");
      nsFrame::ListTag(stdout, parentFrame);
      printf(" is special\n");
    }
#endif
    return ReframeContainingBlock(aPresContext, parentFrame); /*** HERE ***/
  }
The testcase shows the same thing, just a lot less times. 

In the testcase, and I presume in the URL, the problem is that there is a FONT
tag that contains a lot of stuff it should not (fonts cannot legally contain
blocks). Removing the FONT tag from here:

<font face="Arial, sans-serif" size="-1">
<!--content-->


<!--*******************************************************************-->
<!--page content here (white space)...    *****************************-->

fixes the testcase, and will probably fix the real page too.

I'll attach the same testcase with the FONT removed, but there is probably
nothing we can do to fix this.

Comment 6

[Marc Attinasi]

Attachment: Same as the previous testcase but with the unclosed FONT removed

Comment 7

[Marc Attinasi]

Marking as a dup of bug 109181 - a meta-bug for this class of problem with
ReframeContainingBlock

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