CHECK that CommitNavigation/CommitFailedNavigation IPCs always commit.
Currently, state synchronization between the browser and the renderer process is complicated and buggy for cross-process navigations. The renderer process is responsible for processing the commit IPC and then reporting success back up to the browser process, which then updates its state. However, it's unclear if this can lead to races. Instead, if it is possible to assume that one `CommitNavigation()` IPC from the browser always maps to one committed navigation in the renderer, the code can be simplified to remove multiphase navigation commits. This means the browser would be able to mark a provisional local frame as committed as soon as it sends a commit IPC to the renderer for that frame. As an initial step in this direction, this CL implements a renderer-side `CHECK()` that a request to commit a navigation from the browser always results in a committed navigation, with some initial exemptions for fallback content for embedded content, et cetera. However, this new `CHECK()` exposed some existing bugs in MHTMLx handling. The browser side navigation code does not know enough about an MHTML archive to determine if a commit will succeed or fail. Instead, the browser always assumes that a subframe navigation request will succeed and simply always calls `CommitNavigation()`. Unfortunately, the renderer silently ignores commit requests in subframes if the associated resource cannot be found in the MHTML archive, which triggers the new `CHECK()`. To fix this, committing a navigation to a non-existent MHTML resource will now simply commit a document constructed from an empty string with the text/html MIME type. This required updating the expectations for some existing MHTML tests that tested loading of non-existent MHTML resources. Before, the last committed URL would simply be empty, since the commit would silently be dropped. After, the last committed URL is now the URL of the non-existent resource. Finally, NavigationMhtmlBrowserTest.IframeAboutBlankNotFound exhibited a large number of complex interactions that still are not fully understood. It looks like the renderer now reports load completion *after* the about:blank fragment navigation completes, so update the test expectations accordingly... Bug: 999255 Change-Id: I2f9ac23b5668886b8b3bbbdcb7925f8784480c25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2335323 Commit-Queue: Daniel Cheng <dcheng@chromium.org> Reviewed-by:Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/master@{#796508}
Showing
This diff is collapsed.
Please register or sign in to comment