AppCache: fix a race when registering new backend on navigation
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}
Showing
Please register or sign in to comment