Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cherry-pick 265870.357@safari-7616-branch (8e677b3). https://bugs.web…
…kit.org/show_bug.cgi?id=260046 Main frame URL is wrong after server-side redirect to a page serving the COOP header https://bugs.webkit.org/show_bug.cgi?id=260046 rdar://111855179 Reviewed by Brent Fulgham and Alex Christensen. In the poc, the page is opening a popup (without opener) to the same origin URL1. This URL1 does a server-side redirect to URL2 which serves the `COOP: same-origin` HTTP header. After the navigation, Safari was displaying URL1 instead of URL2 in the URL bar. It is important to note that that 2 process-swap occur here. The first occurs when we do the navigation to URL1 in a popup that doesn't have an opener (in the decidePolicyForNavigationAction). The second one occurs when we receive the COOP header from URL2 (on navigation response). In ProvisionalPageProxy::didCreateMainFrame(), we have code which does the following: ``` if (previousMainFrame && !previousMainFrame->provisionalURL().isEmpty()) { // In case of a process swap after response policy, the didStartProvisionalLoad already happened but the new main frame doesn't know about it // so we need to tell it so it can update its provisional URL. m_mainFrame->didStartProvisionalLoad(previousMainFrame->provisionalURL()); } ``` During the second process-swap, we forward the provisional URL from the committed frame to the provisional one. This is because the didStartProvisionalLoad IPC was handled by the committed main frame, before we decided to process-swap on resource response later on. As a result, the provisional main frame doesn't know yet about the provisional load and we have to let it know about it so it sets its provisional URL. This worked fine in the usual case where the COOP process-swap doesn't follow another process swap. However, in this case, the provisional URL got updated by an earlier server side redirect which got handled by a provisional frame, not the committed one. As a result, the committed frame didn't know about the latest provisional URL, only the original one before the server side redirect. To address the issue, whenever a provisional main frame receives a server-side redirect, we now let the committed main frame know about it too so that the committed frame's provisional URL always stays up-to-date. As a result, when ProvisionalPageProxy::didCreateMainFrame() forwards the committed frame's URL to the new provisional frame, it is now accurate. * Source/WebKit/UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared): * Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm: Canonical link: https://commits.webkit.org/265870.357@safari-7616-branch
- Loading branch information