Bug 20587 – WebKit eats CPU on http://uk.sun.com/tryandbuy/products.jsp

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[Ceri Davies]

Visiting http://uk.sun.com/tryandbuy/products.jsp causes Safari to eat CPU until you kill it.

[Matt Lilek]

Definitely confirmed with r36029 debug build on Leopard - it ate into the second core of my machine and the default sample from Activity Monitor was over 100 MB:

Total number in stack (recursive counted multiple, when >=5):
        115201       WebCore::RenderBlock::isSelfCollapsingBlock() const
        7234       WebCore::RenderBlock::markAllDescendantsWithFloatsForLayout(WebCore::RenderObject*)
        5980       WebCore::RenderBlock::layoutBlock(bool)
        5979       WebCore::RenderBlock::layout()
        5899       WebCore::RenderBlock::layoutBlockChildren(bool, int&)
        452       WebCore::RenderBlock::collapseMargins(WebCore::RenderObject*, WebCore::RenderBlock::MarginInfo&, int)
        450       WebCore::Element::recalcStyle(WebCore::Node::StyleChange)
        446       WebCore::RenderBlock::calcPrefWidths()
        445       WebCore::RenderBox::minPrefWidth() const
        444       WebCore::RenderBlock::calcBlockPrefWidths()

(In reply to comment #0)
> Visiting http://uk.sun.com/tryandbuy/products.jsp causes Safari to eat CPU
> until you kill it.

When I tried it, CPU consumption was high, but closing the page stopped it immediately. I did not have to kill the Safari process.

Some repaint-only style property inherited by the list markers (opacity, I think) is animated. But that results in a relayout every time (and relayout is quite expensive because the DOM is crazy-deep and so is the render tree, for reasons that might warrant separate investigation) because RenderListMarker::updateMargins() mutates layout properties of the style.

[Philippe Normand]

Now redirects to https://www.oracle.com/uk/index.html which keeps the CPU alive ;)