109161 - usps.com - layout or table handling takes a very long time due to repeated reframing containing block calls from contentAppended

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect)

Description

[Mark Woodruff]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

This renders fine:

http://postcalc.usps.gov/speed.asp?OZ=32807&DZ=32807&P=1&O=0&Char=0&zipok=Continue&LP=package&OV=off&BL=off&Dir=forward&retspec=no

but if you click Priority Mail Help, the layout engine goes into an infinite
loop trying to display this page:

http://new.usps.com/cgi-bin/uspsbv/scripts/content.jsp?D=9743&B=Mail_or_Ship&A=B&U=X&U1=B&U2=H#priority

View source shows the page as appearing to be mostly one long string; there
doesn't seem to be CRLF/LFs between table rows (if that makes a difference).
I'm not sure if it is related to other rendering problems, such as those
handling cnn.com's pages, but there are other rendering problems too:

http://money.cnn.com/markets/

Click on an article. Many of them don't render properly:

http://money.cnn.com/2001/11/07/investing/futrelle/

Reproducible: Always
Steps to Reproduce:
1.
http://postcalc.usps.gov/speed.asp?OZ=32807&DZ=32807&P=1&O=0&Char=0&zipok=Continue&LP=package&OV=off&BL=off&Dir=forward&retspec=no
2. Click Priority Mail Help


Actual Results:  Browser goes into a loop repainting the screen every few
seconds. It never gets to the appropriate anchor. If I hit stop, the partially
rendered text is displayed as one tiny column on the left hand side.

Expected Results:  Should display the appropriate section/anchor in the file.

Since the pages it has trouble rendering include some of the main ones I use on
a daily basis, for me this is a major problem. For others, this might be an
ordinary bug.

Comment 1

[Christopher Hoess (gone)]

I don't know whether this is hitting some edge case in incremental reflow or
what, but it makes Gecko twitch like it's being electrocuted.

Comment 2

[Marc Attinasi]

We are continually reframing due to some content being appended in a
block-in-inline situation.  I hit ReframeContainingBlock several dozen times
loading the blinky-link, then I killed it.  This is getting to be a chronic
performance problem, and in this case, it is beyond a mere performance problem!

Comment 3

[Marc Attinasi]

Hopefully the patch for bug 56894 will fix this - I need to test it...

Comment 4

[Marc Attinasi]

Bulk push to next milestone

Comment 5

[Kevin McCluskey (gone)]

If I go to:

http://postcalc.usps.gov/speed.asp?OZ=32807&DZ=32807&P=1&O=0&Char=0&zipok=Continue&LP=package&OV=off&BL=off&Dir=forward&retspec=no

and click on Priority Mail Help, it does the load the page if I click on the
"stop" button using 2002013103 build on WINNT.

Marking nsbeta1+

Comment 6

[Chris Petersen]

Testcase provided from url. Though this sample may need further reduction, it
reproduces the looping when reloading the document. Document contains a master
table multiple nested tables. I noticed many TD's contained in font elements as
well.

Comment 7

[Chris Petersen]

Attachment: Sample test from url

Comment 8

[Marc Attinasi]

First, it is not an infinite loop - it is just a very long loop.  The page will
load but it take a very long time. The reason it takes so long is that the page
is INCREDIBLY BAD HTML!

There are thousands and thousands of illegal <font> tags in there, and they are
wrapping just about everything.  Unfortunately, that messes us up pretty bad as
we get data in incrementally, we end up having to continually reframe everything
because we are lame at handling block-in-inline situations, and that is what you
get when you have somethign like:

<font><p>sometext</font>

But there is worse than that in this markup. Stuff like

<font face="helvetica, arial" size="-1">
   <ul> 
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#first>First-Class Mail</a></li> 
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#priority>Priority Mail</a></li> 
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href="#priority flat rate">Priority Mail Flat Rate Envelope</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#express>Express Mail</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#parcel>Parcel Post</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#bpm>Bound Printed Matter</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#standard>Media Mail (Book Rate)</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <li><a href=#special>Special Services</a></li>
  </font>
  <font face="helvetica, arial" size="-1">
   <ul>
    <p>
     <li><a href=#cert1>Certificate of Mailing</a></li> 
  </font>

(indentation is mine).

So, the page is very large, and very poorly written, and it tickles a very
performance-challenged area of layout (block-in-inline).

Without attacking this at the parser side to create a cleaner content model, I
do not think that there is much we can do in layout. Optimizing content appended
handling of special block-in-inline situations would be the only real solution
to this kind of problem I think.

I will try to attach the content model so everyone can see the mess we are
expected to layout :)

Comment 9

[Marc Attinasi]

Attachment: content model for the page (from attachment 68903)

The content model shows just how nasty this page is.  Loads of unnecesary
<font> tags, lots of illegal constructs inside of the fonts, etc.

Comment 10

[Marc Attinasi]

BTW: that sample test from teh url causes 465 calls to
nsCSSFrameConstructor::ReframeContainingBlock - that is what is taking so long.

I want to move this to evangelism - clearing nsbeta1+ to get mgr approval...

Comment 11

[Marc Attinasi]

I thought of another idea that might help this class of performance problems. 
Here goes:

If we have special-inline-block situations and end up calling
ReframeContainingBlock more than, say, 3 times, we set a flag to tell the
ContentSink not to give layout incremental content updates.  Then, when the
document is completly loaded and the content model built, the content sink can
send it all over to layout in one shot.  We lose incremental loading, but we
also avoid the incredible performance problem of repeatedly destroying and
building all of the frames (465 times, in this case).

I'll play with it: this class of problems is not altogether rare, though
generally not as bad as this page.

Comment 12

[Marc Attinasi]

bug 109181 convers the issue of minimizing the use of ReframeContainingBlock, so
this bug should be evangelized.

Comment 13

[Kevin McCluskey (gone)]

Reassigning to evang.

Comment 14

[Tristan Nitot]

Wrong component/region (or was USPS relocated to Africa and no one told me ?)
Component: African->US Gov

Comment 15

[Matthias Versen [:Matti]]

*** Bug 127232 has been marked as a duplicate of this bug. ***

Comment 16

[Matthias Versen [:Matti]]

*** Bug 127472 has been marked as a duplicate of this bug. ***

Comment 17

[Tristan Nitot]

re-assigning to default owner

Comment 18

[Kai Lahmann (is there, where MNG is)]

does it now.

Comment 19

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg