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

• Component: Page Loading
• Status: RESOLVED WONTFIX

[Brady Eidson]

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

[Brady Eidson]

*sigh*

Nevermind.

A single layouttest that broke with this change revealed why we cannot make it without causing much larger disruption.

That change would be inappropriate at this time.