crash log for WebKitTestRunner (pid 24180): STDOUT: <empty> STDERR: ASSERTION FAILED: m_loadState == LoadStateProvisional /home/balazs/WebKitGit/Source/WebKit2/UIProcess/WebFrameProxy.cpp(164) : void WebKit::WebFrameProxy::didCommitLoad(const WTF::String&, const WebKit::PlatformCertificateInfo&) _ZN6WebKit13WebFrameProxy13didCommitLoadERKN3WTF6StringERKNS_23PlatformCertificateInfoE+0x44 _ZN6WebKit12WebPageProxy21didCommitLoadForFrameEmRKN3WTF6StringEbRKNS_23PlatformCertificateInfoEPN7CoreIPC15ArgumentDecoderE+0x12e) _ZN7CoreIPC18callMemberFunctionIN6WebKit12WebPageProxyEMS2_FvmRKN3WTF6StringEbRKNS1_23PlatformCertificateInfoEPNS_15ArgumentDecoderEEmS4_bS7_EEvRKNS_10Arguments4IT1_T2_T3_T4_EESB_PT_T0_+0x87 _ZN7CoreIPC21handleMessageVariadicIN8Messages12WebPageProxy21DidCommitLoadForFrameEN6WebKit12WebPageProxyEMS5_FvmRKN3WTF6StringEbRKNS4_23PlatformCertificateInfoEPNS_15ArgumentDecoderEEEEvSE_PT0_T1_+0x61 _ZN6WebKit12WebPageProxy29didReceiveWebPageProxyMessageEPN7CoreIPC10ConnectionENS1_9MessageIDEPNS1_15ArgumentDecoderE+0xc3a
Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10.
(In reply to comment #1) > Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10. No, it is WebKit2.
The fact is that no matter what test we run after LayoutTests/fast/loader/document-destruction-within-unload.html (the previous of the one in the title), we get this assertion.
This does not seems to be Qt specific, it actually has a Mac counterpart: #66783. I believe we would hit this assertion on Mac-WK2 if it were not be skipped.
(In reply to comment #4) > This does not seems to be Qt specific, it actually has a Mac counterpart: #66783. I believe we would hit this assertion on Mac-WK2 if it were not be skipped. I learned how to to refer to another bug: bug 66783
I tried to catch the order of load events in WebFrameProxy. I signed where I think the problem is. 0x7f6115d08f00 -- didStartProvisionalLoad: url=about:blank 0x7f6115d08f00 -- didCommitLoad: url=about:blank 0x7f6115d08f00 -- didFinishLoad: url=about:blank 0x7f6115d08f00 -- didStartProvisionalLoad: url=fast/loader/document-destruction-within-unload.html 0x7f6115d08f00 -- didCommitLoad: url=fast/loader/document-destruction-within-unload.html 0x7f6115d08e60 -- didStartProvisionalLoad: url=fast/loader/resources/document-destruction-within-unload-iframe.html 0x7f6115d08e60 -- didCommitLoad: url=fast/loader/resources/document-destruction-within-unload-iframe.html 0x7f6115d3cd20 -- didStartProvisionalLoad: url=fast/loader/resources/does_not_exist 0x7f6115d08dc0 -- didStartProvisionalLoad: url=fast/loader/resources/document-destruction-within-unload.svg 0x7f6115d3cd20 -- didFailProvisionalLoad: url=fast/loader/resources/does_not_exist 0x7f6115d08dc0 -- didCommitLoad: url=fast/loader/resources/document-destruction-within-unload.svg 0x7f6115d08dc0 -- didFinishLoad: url=fast/loader/resources/document-destruction-within-unload.svg 0x7f6115d08e60 -- didFinishLoad: url=fast/loader/resources/document-destruction-within-unload-iframe.html 0x7f6115d08f00 -- didFinishLoad: url=fast/loader/document-destruction-within-unload.html 0x7f6115d08e60 -- didStartProvisionalLoad: url=fast/loader/resources/document-destruction-within-unload-iframe.html 0x7f6115d08e60 -- didFailProvisionalLoad: url=fast/loader/resources/document-destruction-within-unload-iframe.html 0x7f6115d08e60 -- didCommitLoad: url= <============= this commit seems to be the problem. 0x7f6115d08f00 -- didStartProvisionalLoad: url=about:blank 0x7f6115d08f00 -- didCommitLoad: url=about:blank 0x7f6115d08f00 -- didFinishLoad: url=about:blank 0x7f6115d08f00 -- didStartProvisionalLoad: url=css1/basic/comments.html 0x7f6115d08f00 -- didCommitLoad: url=css1/basic/comments.html 0x7f6115d08f00 -- didFinishLoad: url=css1/basic/comments.html Let's look at the iframe loaded in the test (fast/loader/resources/document-destruction-within-unload-iframe.html): <html> <body> <script> function runTest() { var test = document.getElementById('root').contentDocument; test.firstChild.setAttribute('onunload', "parent.clearUs();"); location.reload(); } function clearUs() { document.write(); parent.done(); } </script> <object data="does_not_exist"></object> <object data="document-destruction-within-unload.svg" id="root" onload="runTest();"></object> </body> </html> So, upon loading the svg file, the iframe does a reload. This is why didStartProvisionalLoad called again for it. On the other hand the onunload handler of the svg element does document.write() which results in cancelling the load, and didFailProvisionalLoad is called. I think it is correct so far. The question is how can be data committed the this cancelled load after that (which results in didCommitLoad called)? In bug 66783 the same seems to happen, and if I put equivalent assertions in FrameLoaderClientQt, I get the same fail (with Qt WK1 of course), so basically it seems to be a general bug in loader code.
I checked, it also asserts on Mac.
Fixed in http://trac.webkit.org/changeset/127347, thanks to Nate Chapin. *** This bug has been marked as a duplicate of bug 66783 ***