[WK2] ASSERTION FAILED: m_loadState == LoadStateProvisional at fast/loader/document-with-fragment-url-1.html

• Component: WebKit2
• Status: RESOLVED DUPLICATE

[Balazs Kelemen]

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

[Balazs Kelemen]

Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10.

[Balazs Kelemen]

(In reply to comment #1)
> Seen in local test session, WebKit1 debug, r120688, desktop, Ubuntu 11.10.

No, it is WebKit2.

[Balazs Kelemen]

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.

[Balazs Kelemen]

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.

[Balazs Kelemen]

(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

[Balazs Kelemen]

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.

[Balazs Kelemen]

I checked, it also asserts on Mac.

[Balazs Kelemen]

Fixed in http://trac.webkit.org/changeset/127347, thanks to Nate Chapin.

*** This bug has been marked as a duplicate of bug 66783 ***