Skip to content
  • ggaren's avatar
    WebCore: · 3d613f1f
    ggaren authored
            Added test case for <rdar://problem/4268278> Submitting a form in onUnload event
            handler causes crash in -[WebDataSource(WebPrivate) _commitIfReady:]
    
            * manual-tests/onunload-form-submit-crash.html: Added.
    
    WebKit:
    
            Reviewed by Eric.
    
            Manual testcase added:
            WebCore/manual-tests/onunload-form-submit-crash.html
    
            - Fixed <rdar://problem/4268278> Submitting a form in onUnload event
            handler causes crash in -[WebDataSource(WebPrivate) _commitIfReady:]
    
            The problem is that the form submission in the unload event kicks off
            a new load in the midst of the load that caused the unload event to
            fire in the first place, so the two loads stomp each other.
    
            The solution is to cancel the first load and let the unload handler's
            load win. (Firefox does the same.)
    
            * WebView.subproj/WebFrame.m:
            (-[WebFrame _transitionToCommitted:]): Moved call to -closeURL up
            the call stack to _continueLoadRequest. (See below.) This has the
            side-effect of always firing the unload event, even if the new
            datasource never becomes committed, which seems like a good thing.
    
            (-[WebFrame _continueLoadRequestAfterNavigationPolicy:formState:]):
            Call -closeURL here, instead of in _transitionToCommitted,  so that the
            unload handler can fire before we initialize any part of the load.
    
            Check provisionalDataSource for nil to discover if the unload event
            kicked off its own load.
    
            Cleared up some coments.
    
            (-[WebFrame _detachFromParent]):
            It turns out that if you close the window instead of just navigating
            to a new page, you get an alternate assertion failure/crash because
            the load kicked off by the unload event handler generates resource
            loader callbacks after the associated WebFrame/WebView has disappeared.
    
            The nifty solution here is just to reverse the order of calls to
            -stopLoading and -closeURL, thus guaranteeing that -stopLoading has the
            last word when you close a window.
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@11841 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    3d613f1f