89467 2012-06-19 07:13:03 -0700 [WK2] ASSERTION FAILED: m_loadState == LoadStateProvisional at fast/loader/document-with-fragment-url-1.html 2012-09-04 05:03:55 -0700 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 66783 LayoutTestFailure, Qt, QtTriaged P1 Normal --- 79668 1 kbalazs webkit-unassigned abarth jturcotte oldest_to_newest 652413 0 kbalazs 2012-06-19 07:13:03 -0700 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 652416 1 kbalazs 2012-06-19 07:14:02 -0700 Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10. 652418 2 kbalazs 2012-06-19 07:15:30 -0700 (In reply to comment #1) > Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10. No, it is WebKit2. 658537 3 kbalazs 2012-06-27 04:49:42 -0700 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. 659339 4 kbalazs 2012-06-28 01:50:06 -0700 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. 659347 5 kbalazs 2012-06-28 02:07:05 -0700 (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 659352 6 kbalazs 2012-06-28 02:23:06 -0700 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. 659614 7 kbalazs 2012-06-28 10:57:01 -0700 I checked, it also asserts on Mac. 710991 8 kbalazs 2012-09-04 05:03:55 -0700 Fixed in http://trac.webkit.org/changeset/127347, thanks to Nate Chapin. *** This bug has been marked as a duplicate of bug 66783 ***