[Webkit-unassigned] [Bug 26230] New: JavascriptURL as frame src crasher.

[bugzilla-daemon at webkit.org]

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

           Summary: JavascriptURL as frame src crasher.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Blocker
          Priority: P1
         Component: Frames
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: michaeln at google.com


This is a blocking bug for chrome.
See http://code.google.com/p/chromium/issues/detail?id=12161

The incorrect javascript handling is a secondary issue. The blocker is the
crasher.

This webkit bug was split out of bug 16855, which is an umbrella for all manner
of issues related to javascript urls. I hijacked that umbrella too much for
this particular issue already, so have opened this new more focused bug. There
are comments (and preliminary patches) specific to chrome's issue in bug 16855
that I have not copied here (so please see them there).

As mentioned in the comments over there, I'm not so sure about the extra call
to stopLoader(false) in FrameLoader::executeIfJavaScriptURL. What seems like is
really missing is a call to cache()->loader()->cancelRequests(docLoader) for
the document being torn down in the act of replacing the document. The call to
stopLoader(false) gets that done and much much more. I'm concerned about what
side effects the much much more may have (although all layout tests do pass).

I took a few other stabs at it.

1) In DocumentLoader::stopLoading() call cancelRequests(). The method comments
sound like this would be appropiate for that method.
// Cancels the data source's pending loads.  Conceptually, a data source only
loads
// one document at a time, but one document may have many related resources. 
// stopLoading will stop all loads initiated by the data source, 
// but not loads initiated by child frames' data sources -- that's the
WebFrame's job.
But... a handful of layout tests fail as a result.

2) In FrameLoader::executeIfJavaScriptURL() replace the call to
stopLoading(false) with the more focused call to cancelRequests(). This alone
resolves the very specific crashing bug that I'm seeing with javascript urls
that construct the document programatically.

I'm concerned there are other scenarios where the Document/DocLoader will get
blown away while requests are still pending. We're seeing a number of stack
traces that indicate that has occurred sometime after the fact. I think its
unlikely that javascript urls in frameset documents are responsible for all of
them. We think differences in protective refcounting between jsc and v8
bindings and or differences in gc strategies may be involved.

Given the uncertainty, and the sevirity (CRASH!!!)... i took another stab at it
that casts a wider net.

3) In DocLoader::~DocLoader(), dont just ASSERT(!m_requestCount), proactively
cancel them... behind a PLATFORM(CHROMIUM) flag. This should not affect other
platforms as they should never have active requests at dtor time (per the
existing assertion).

I'm leaning towards option 3 (for m3) unless we can determine a better fix real
soon now.


-- 
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.