GitLab

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}