[Webkit-unassigned] [Bug 143155] New: Frame::stopAllLoaders() does not always cancel scheduled redirects

[bugzilla-daemon at webkit.org]

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

            Bug ID: 143155
           Summary: Frame::stopAllLoaders() does not always cancel
                    scheduled redirects
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: beidson at apple.com

Frame::stopAllLoaders() does not always cancel scheduled redirects

The developer impact is that using API to stop a frame from loading (e.g. WKBundleFrameStopLoading) doesn't actually halt an already scheduled redirect.
The user impact is that hitting the "stop" button in their browser - or performing some other user gesture to freeze loading on the current page - will not always cancel a scheduled redirect away from the current page.

----

Calling FrameLoader::stopLoading() on each FrameLoader is an important part of "stop all loaders" but unfortunately it doesn't always get called.

stopAllLoaders() walks the frame tree, calling in to each Frame, which calls stopLoading() on their DocumentLoaders.

DocumentLoaders are who are in charge of calling FrameLoader::stopLoading() directly for their Frame, but they often do not actually call it.

There is a (apparently long standing) optimization to only call stopLoading() on the Frame if the DocumentLoader is currently loading or parsing. Unfortunately, the DocumentLoader can be done loading and parsing while its Frame still has a "load" active in the form of a scheduled redirect.

I propose DocumentLoader be much less conditional about when it tells its FrameLoader to stopLoading(), and looking at the body of FrameLoader::stopLoading() suggests there will be no negative side effects *besides* actually cancelling scheduled redirects.

This will all make more sense with the upcoming patch.

rdar://problem/20331979

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150327/e489ef66/attachment-0002.html>