[Webkit-unassigned] [Bug 20073] New: Pending resource requests not always stopped when new request is loaded

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 16 22:26:20 PDT 2008


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

           Summary: Pending resource requests not always stopped when new
                    request is loaded
           Product: WebKit
           Version: 526+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jalkut at red-sweater.com


I've discovered a situation where scheduled resource requests for a frame are
not stopped when a new request is loaded into the frame.

The worst case scenario is that the requests are then attempted to be fulfilled
while the loader is in provisional mode, where the SubresourceLoader will fail
by default, leaving the CachedResource in "error" state. This cached resource
will then live on, fulfilling future requests for the resource. If for instance
the resource in question is an image, it will cause a permanent "broken image"
for that resource until the CachedResource is cleared.

I will attach to this bug two files:

WebCoreLoaderBug.zip - This demo project is my best and most concise attempt to
lead you to reproduce the bug yourself. Unfortunately, it's not 100%. It
happens quite predictably and regularly on my PowerPC G5, but I think it has a
lot to do with timing. Considering the nature of the bug, the frame must go
into provisional mode and still be in provisional mode while a pending resource
request is serviced, in order for the bug to reveal itself.

FrameLoaderFix.patch - On my machine, this one line of code (and many lines of
comments) seems to fix the bug. When a new request is opened in a frame, one
would expect that all outstanding requests from the previous frame content
would be canceled.  Indeed, stopAllLoaders() does get called, but the very
similarly named "stopLoading()" does not get reached.  It's important for
stopLoading() to be reached, because otherwise the crucial call to
cancelRequest() in loader.cpp is not reached, and the queued requests are left
in the priority queue.


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



More information about the webkit-unassigned mailing list