NEW 104860
Be more consistent about client redirects 
https://bugs.webkit.org/show_bug.cgi?id=104860
Summary Be more consistent about client redirects
Charles Reis
Reported 2012-12-12 16:39:17 PST
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().
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2012-12-13 09:40:56 PST
Is it also a client redirect when it's caused by FrameLoaderClient::dispatchWillSendRequest?
Note You need to log in before you can comment on or make changes to this bug.