When attempting to load fed-soc.org with TOT WebKit based Safari, Safari beachballs while loading the page. Content is rendered, but the progress bar and spinner never complete and Safari uses 100% of the CPU (500 MHz iBook). Only recourse is to force quit Safari.
Tested in Safari 412.2, same result.
Similar results in V312, but it eventually recovers from spinning pizza, so does not crash (1.25 alu powerbook). Hang lasts about 20 seconds.
Created attachment 3736 [details] Sample during spin, 9/2 ToT It eventually completes with 9/2 ToT, but does spin for a while. Sample attached. It's slow in Camino as well, but not nearly this slow.
reproduceable, however, the spinner completes and the site is usable for me.
The most likely cause, AFAICT is the huge (1050x1000) background image, http://www.fed-soc.org/images/madisonbackground.gif. I can reproduce this both on 2.0.3 and on r12479. The loading *does* complete, even on my G3/700 iBook. It just takes a lot of time, and Safari is hanging/unresponsive (including beachball) during it.
Reassigning to webkit-unassigned, to make sure more people see this.
Confirmed.
Moving to "New Bugs" from "WebSite" since the latter is used for webkit.opendarwin.org. The background image mentioned in Comment #5 is only 9 KB (although the authors of this site really need to learn how to use CSS). This issue needs to be reduced to find the actual cause, so adding NeedsReduction keyword. The source appears to have Dreamweaver JavaScript functions, so beware!
A quick Shark Time Profile of the Safari while the page is beach-balling shows that most of the time is spent in KJS. Therefore, moving this bug to the JavaScript component. It still needs a reduction, though.
I think ggaren would be interested in this bug since it deals with JavaScript and performance issues. Adding him to CC list.
This looks like the oft-reported bug that JavaScript execution freezes the browser. We have plans to fix this with "tree code."
The other issue here is that a for loop is getting a value from a DOM node, and each get causes a re-layout. In tree view, you can see that "KJS::DOMNode::getValueProperty(KJS::ExecState*, int) const" calls "DOM::DocumentImpl::updateLayoutIgnorePendingStylesheets()." In heavy view, you can see that the heaviest function calls are all layout calls: 327 khtml::RenderObject::updateWidgetPositions() 26 DOM::ElementImpl::recalcStyle(DOM::NodeImpl::StyleChange) 26 khtml::RenderBlock::lowestPosition(bool, bool) const 25 khtml::RenderLayer::updateLayerPositions(bool, bool) 22 khtml::RenderBlock::rightmostPosition(bool, bool) const 20 khtml::RenderLayer::computeRepaintRects() 19 khtml::RenderBox::computeAbsoluteRepaintRect(QRect&, bool) 18 khtml::RenderFlow::lowestPosition(bool, bool) const 15 khtml::RenderBlock::layoutBlock(bool) 15 khtml::RenderFlow::rightmostPosition(bool, bool) const 13 khtml::RenderBlock::getAbsoluteRepaintRectIncludingFloats(QRect&, QRect&) 13 khtml::RenderFlow::getAbsoluteRepaintRect() 12 khtml::RenderBox::getAbsoluteRepaintRect() 12 khtml::RenderObject::isFloatingOrPositioned() const I'd love to see a reduction that showed what kind of JavaScript get caused this re-layout. Looks like it's something in one of the inline <script> tags. One approach would be to set a breakpoint on DocumentImpl::updateLayoutIgnorePendingStylesheets and get information from the calling stack frame.
Created attachment 7047 [details] Reduction Reduction. These scripts for a complex 4-level flyout menu consume most of the time. Rendering of the page (approx. time in seconds, iMac 1.9GHzG5 1.5GB): Fx1.5.0.1 : IE5.2Mac : Opera8.51 : Webkit r13265 4 : 5 : 9 : 28 I used base to reproduce this problem. When I download the scripts, remove the base and open the page locally, there is no problem with that page. Hope this helps.
Created attachment 12260 [details] Gzipped webarchive of page on 2007/01/06
As of WebKit r18639, the menu on the fed-soc.org web site is misplaced. See Bug 12141 for details.
Although the website has been update to be much more modern, the webarchive David attached still causes a beachball, even with Safari 4.0.3 on Leopard/PPC with a Quad G5. I'm just going through my old bugs and wanted to bump this and see whether it's still something to be fixed.
The attached webarchive opens nice & quick for me on Safari 5.0. Based on the bug# I guess this bug is archaic, but please reopen if the issue still repros for you.
Not that quick for me, even on an i7 iMac and it's still slow enough on my Quad G5 to cause the beach ball for a few seconds before loading completes. Even my iMac takes a few seconds to open it, though not enough to cause the beach ball. I don't know if even the lowest Intel Mac would produce the beach ball but like I said, my Quad G5 certainly does.
Takes my i7 iMac approximately 3 - 4 seconds to open the archive, with the Quad G5 taking 10 seconds. JS issue I'd say, since that's the biggest difference between PPC and Intel WebKit, AFAIK.
:-( 10s is certainly an improvement from 28s, but I guess I can't call this fixed, so reopening. Retitling to reflect that this appears to be an interpreter-related issue.
My brief sampling gives the following as the hottest part: 0.0% 74.4% JavaScriptCore JSC::Interpreter::privateExecute(JSC::Interpreter::ExecutionFlag, JSC::RegisterFile*, JSC::ExecState*, JSC::JSValue*) 0.0% 32.3% WebCore WebCore::jsElementOffsetHeight(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 26.3% WebCore WebCore::jsElementOffsetWidth(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 8.2% WebCore WebCore::jsElementOffsetLeft(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 6.4% WebCore WebCore::jsElementOffsetTop(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 0.8% WebCore WebCore::JSCSSStyleDeclaration::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&) 0.2% 0.2% JavaScriptCore JSC::Interpreter::privateExecute(JSC::Interpreter::ExecutionFlag, JSC::RegisterFile*, JSC::ExecState*, JSC::JSValue*) 0.0% 0.1% WebCore WebCore::jsElementStyle(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 0.1% JavaScriptCore JSC::jsTypeStringForValue(JSC::ExecState*, JSC::JSValue) 0.0% 0.0% JavaScriptCore JSC::JSValue::get(JSC::ExecState*, JSC::Identifier const&, JSC::PropertySlot&) const 0.0% 0.0% JavaScriptCore WTF::tryFastRealloc(void*, unsigned long)
Menu is still misplaced as well, as noted by David in #15.
0.0% 32.3% WebCore WebCore::jsElementOffsetHeight(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 26.3% WebCore WebCore::jsElementOffsetWidth(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 8.2% WebCore WebCore::jsElementOffsetLeft(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 6.4% WebCore WebCore::jsElementOffsetTop(JSC::ExecState*, JSC::JSValue, JSC::Identifier const&) 0.0% 0.8% WebCore WebCore::JSCSSStyleDeclaration::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&) Seems that my 2006 comment identifying possibly n^2 layout behavior may still be apt.
This bug was interpreter only, the classic interpreter has now been removed from the tree.