317561 - Hang CPU loop on google "view as HTML"

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[bill]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051119 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051119 Firefox/1.6a1

Search google for: statistics "standard error for ratios
  (note placement of double quote)
google page comes up as usual.
Click on view as HTML
Deerpark alpha 2 hangs

The cursor turns to the hour glass. Within a few seconds firefox
is consuming all the CPU it can get its hands on. It never comes back.
Repeated three or more times whilst trying to report this problem.
Error report sent via desktop icons to microsoft
(my reading of talkback web pages suggests it cannot be used with this sort of fault).

Reproducible: Always

Actual Results:  
see screenshot


google URL is
http://216.239.59.104/search?q=cache:3Mq3Vq_p6RgJ:www.cdc.gov/nchs/data/series/sr_02/sr02_125.pdf+statistics+%22standard+error+for+ratios%22&hl=en
if this is loaded via usual then browser hands in same way
I tried 2 other browsers, both are ok
Netscape 7.2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
IE 6

Comment 1

[bill]

screen shot is at 
http://www.cs.ucl.ac.uk/staff/W.Langdon/317561.gif
code downloaded (via Netscape 7.2) is at
http://www.cs.ucl.ac.uk/staff/W.Langdon/317561.html

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051123 Firefox/1.6a1 ID:2005112305

This is a regression somewhere between 25-Nov-2004 and 05-Dec-2004.

Comment 3

[Martijn Wargers (dead)]

I can see the regression between 2004-11-26 and 2004-11-28:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-26+06%3A00%3A00&maxdate=2004-11-28+09%3A00%3A00&cvsroot=%2Fcvsroot
So I think this could be a regression from one of the check-ins from bug 201897.
This one exactly:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsAbsoluteContainingBlock.cpp&rev1=1.54&rev2=1.55&root=/cvsroot

Comment 4

[bill]

(In reply to comment #3)
Can I delete http://www.cs.ucl.ac.uk/staff/W.Langdon/317561.html ?
Have you taken a copy of it?
I dont like to leave broken www pages on my home page.

Thanks again
Bill

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase from url

It can be attached to the bug.

Comment 6

[Martijn Wargers (dead)]

Bug 160665 is also mentions Google "view as HTML", so that bug is probably related to this.

Comment 7

[Mats Palmgren (inactive)]

Some statistics on the first testcase:
2004-11-26-08: 2 seconds to render
2005-01-11-07: 13 minutes
2005-11-25-02: 8.5 minutes

Number of calls to nsAbsoluteContainingBlock::ReflowAbsoluteFrame:
Aug 2004 (roughly) debug build: 22135
current debug build: 13686788

The reason is the second reflow introduced in bug 201897 for
shrink-to-fit calculation. This is by design and not an error.
Of course, this results in bad performance in the case we have
nested shrink-to-fit abs. blocks, in the worst case 2^N where
N is the depth of the tree.

In the first testcase there are several bogus end tags:

<div style="position:absolute;top:476;left:55"><nobr>Health St<b style="color:black;background-color:#ffff66">atistics</nobr></</b>div>

So the DIV becomes an ancestor for the rest of the elements
and there are 11 of these errors generated by Google's PDF
to HTML translator. For the short term, I think the best
solution is to make Google fix their bug - the page renders
within a few seconds with the above markup errors fixed.
I filed Evangelism bug 319081 on that.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This got fixed by the reflow branch landing.

Comment 9

[Eli Friedman]

Did you mean to close this, or are you keeping it open for performance profiling?

Comment 11

[Daniel.S]

Attachment: crashtest

A lot of open abs pos div elements.
Fx2: hang, Fx3+: works perfectly

Comment 12

[Boris Zbarsky [:bzbarsky]]

Pushed the test as http://hg.mozilla.org/mozilla-central/rev/1f9b126ecec0