Bug 104860
| Summary: | Be more consistent about client redirects | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Charles Reis <creis> |
| Component: | WebCore Misc. | Assignee: | Charles Reis <creis> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, fishd, japhet |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Charles Reis
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
Is it also a client redirect when it's caused by FrameLoaderClient::dispatchWillSendRequest?