Visiting http://uk.sun.com/tryandbuy/products.jsp causes Safari to eat CPU until you kill it.
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.
Now redirects to https://www.oracle.com/uk/index.html which keeps the CPU alive ;)