I'm seeing this on Chromium, Safari and other Webkit-based browsers like Midori and Epiphany, on Linux, OSX and Windows. It looks like this *doesn't* happen on FreeBSD. The problem is that sometimes the browser tab hangs, CPU shots to 100% and after a while the browser asks if it should kill the page. This happens on a website I'm building with some friends. With other browsers everything is fine, while with Webkit-based ones sometimes the SAME page hangs. Other pages work fine. I tried narrowing down the problem: - disabled javascript from the browser: nothing changes - testing on a _local_ server (running the site at localhost): works everytime - testing on a local server but going through the Internet (via a virtual server on the DSL router): problem gets back So I *think* this is something related to the render-as-you-load system, maybe there's something that trips it when there's some lag loading the page? I think this is also related to the number of nested divs on the page, since with simpler ones there's no problem.
I can not reproduce this with Safari 5.1.3 on Mac OS X. Could you please attach a spin log for Safari or WebProcess (whichever is frozen)? To make one, please use /Applications/Utilities/Activity Monitor.app
Created attachment 166525 [details] Spin log of the stuck process I've finally managed to take hold of a Mac, here's the spin log, thanks!
I don't see a complete hang in the stack trace, just being very busy laying out a super deep render tree.
We'll probably need a reproducible case to make progress here, as the provided URL doesn't make WebProcess hang.
That is part of the problem, the process hangs only sometimes, even when just refreshing the same page :( Or do you mean that at your end it never hangs?
I'm not able to repro the hang in Chromium Version 23.0.1271.1 dev. Do I need to refresh the page or is there some set of steps to get it to hang reliably?
Please re-open if you have additional information. I'm happy to investigate further if there is a reliable reproduction.
It's possible that somehow we're getitng into an infinite loop in layoutBlockChildren(), but that seems unlikely: + 2086 WebCore::RenderBlock::layoutBlockChildren(bool, int&) (in WebCore) + 647 [0x10e5e8bc7] + 1811 WebCore::RenderBlock::layoutBlockChild(WebCore::RenderBox*, WebCore::RenderBlock::MarginInfo&, int&, int&) (in is where the sample diverges.
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderBlock.cpp&exact_package=chromium&q=RenderBlock.cpp&type=cs&l=2364 is the function in question.
It's possible that handleSpecialChild() fails to actually handle the child, leaving us in an infinite loop. in some case.
Nevermind. What I proposed is impossible. The loop can't be infinte that way. It would have to have a box which pointed to itself to be infinite.
I tried a little harder, and could reproduce the hang with Safari 6.0.1. But I couldn't reproduce with a recent WebKit build, so this seems fixed indeed. Please test with a recent nightly from <http://nightly.webkit.org>.
I tried installing Safari 5.1.7 on Windows and running "WebKit.exe" from the nightly release, is this the right way to test a WebKit nightly?
I think that nightlies still happen to work on Windows for now, so what you mentioned should do it. We don't put any effort in making nightlies work with anything but the latest Safari release however, which is currently 6.0.1.
I see... Well I've tested it on OSX too and it looks like it doesn't hang anymore, indeed :) A last question then: since in the meantime I had devised a workaround to provide Webkit browsers with "simplified" pages, how can I know that I'm talking to a fixed Webkit? Should I check the user agent for Webkit versions >= 537? (Safari 6.0 has Webkit 536)
We never comment on future Apple releases.
For Chromium you shouldn't need to check, since something like 99% of users will always be running the latest release. The release schedule is public: http://www.chromium.org/developers/calendar if you need it.
Yes I think Chromium won't be a problem but I still need to handle other WebKit-based browsers like the ones on cell phones etc :) Anyway many thanks for your assistance on the whole issue!
For the record, Chrome 21 (WebKit 537.1) still hangs, while Chrome 22 (WebKit 537.4) looks ok.