[Webkit-unassigned] [Bug 26969] New: Fix ASSERT in WebCore::DocumentThreadableLoader::didFail

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26969

           Summary: Fix ASSERT in
                    WebCore::DocumentThreadableLoader::didFail
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: robert at roberthogan.net


Created an attachment (id=32259)
 --> (https://bugs.webkit.org/attachment.cgi?id=32259)
backtrace

Following the instructions at  http://meyerhome.net/~ben/frametest/ (see
https://bugs.webkit.org/show_bug.cgi?id=25283) results in hitting an assert in
WebCore::DocumentThreadableLoader::didFail.

The problem is that DocumentThreadableLoader calls
WebCore::SubresourceLoader::create with a request containing an "OPTIONS"
httpMethod() (set in
WebCore::XMLHttpRequest::makeCrossOriginAccessRequestWithPreflight) . This
method is not supported by QNetworkReplyHandler, which then calls didFail().
This call returns it to DocumentThreadableLoader::didFail, where of course the
m_loader object is still null, since it is still being created.

I think didFail() should expect to handle calls when the m_loader object is
still null. The m_loader object is inaccessible to QNetworkReplyHandler and it
seems reasonable to call didFail() if the http method is not supported and
therefore request has failed.

The following works for me:

void DocumentThreadableLoader::didFail(SubresourceLoader* loader, const
ResourceError& error)
{
    ASSERT(m_client);
    // If the httpMethod() of the request passed to SubresourceLoader::create
is not supported by
    // the client we must expect to call didFail() while m_loader is still
null.
    ASSERT_UNUSED(loader, loader == m_loader || !m_loader);

    m_client->didFail(error);
}

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.