104860 2012-12-12 16:39:17 -0800 Be more consistent about client redirects 2012-12-13 09:40:56 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All NEW P2 Normal --- 1 creis creis ap fishd japhet oldest_to_newest 790057 0 creis 2012-12-12 16:39:17 -0800 In bug 104586, we noticed that the concept of "client redirects" has a lot of different meanings. It could refer to any JavaScript navigation in a page, or it could refer to one that replaces the current history item (e.g., a redirect before the page finishes loading, or the result of replaceState). FrameLoaderClient::dispatchWillPerformClientRedirect appears to be called for any redirect navigation. FrameLoader::quickRedirectComing() appears to refer to whether the navigation will replace the current history item. DocumentLoader::isClientRedirect() is set to quickRedirectComing(), but not until after decidePolicyForNavigation. Darin Fisher points out that we should be more consistent with this concept. Client redirects should refer to cases that replace the current history item. willPerformClientRedirect should only be called in that case. FrameLoader shouldn't need a quickRedirectComing() (especially since it changes over time and needs to carefully be cleared at the right time). DocumentLoader::isClientRedirect() should be set very early on, before decidePolicyForNavigation, since that value will not change for the lifetime of the DocumentLoader. Once these issues are fixed, we can change Chromium's WebDataSource::isClientRedirect to return DocumentLoader::isClientRedirect() instead of quickRedirectComing(). 790692 1 ap 2012-12-13 09:40:56 -0800 Is it also a client redirect when it's caused by FrameLoaderClient::dispatchWillSendRequest?