GitLab

We currently have a race between:
- AppCacheBackendImpl::RegisterHost call coming over it's own mojo pipe and
  looking for precreated AppCacheHost;
- Destroying NavigationRequest, which destroys NavigationHandleImpl, which
  destroys AppCacheHavigationHandle which posts a task to destroy precreated
  AppCacheHost on IO thread.

To combat this, we take AppCacheHavigationHandle from committed NavigationRequest
before destroying it and keep it around in RenderFrameHostImpl. This measure
keeps in a common case when we commit navigation and reach for app cache host.

However, we still cannot assert that we always have a precreated host because
browser can decided to destroy the frame immediately (together with
RenderFrameHostImpl and AppCacheHavigationHandle), while renderer asks for the
AppCacheHost. The best thing we can do in this case is stall AppCacheHost
registration until renderer's frame is inevitably destroyed by the browser's
request.

This is a speculative fix for crashes in issue 941903. Some existing tests, e.g.
http/tests/misc/iframe-reparenting-id-collision.html, easily expose the race,
but since they are not using AppCache, we don't hit the crash point from the bug.

Bug: 941903
Change-Id: I3925d0b9ab9655235b524da561d0e8ba8345fb4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1529381Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#642307}