@cr...@chromium.org: PTAL this change to send PersistentCaches to renderers when committing navigations so that they can fetch resources immediately rather than waiting for an extra round-trip to the browser. Thanks.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
CodeCacheBackendPreparationCommitDeferringCondition::WillCommitNavigation(Could you add a UMA metric to measure the time elapsed from CodeCacheBackendPreparationCommitDeferringCondition::WillCommitNavigation to CodeCacheBackendPreparationCommitDeferringCondition::OnBackendsPrepared?
I am concerned that initiating the ShareReadOnlyConnection process at the time of WillCommitNavigation might be a bit too late. Wouldn't it be better to start the ShareReadOnlyConnection process earlier, such as during NavigationRequest::OnStartChecksComplete() and NavigationRequest::OnRedirectChecksComplete(), similar to the approach in my Renderer-Accessible HTTP Cache prototype?
https://crrev.com/c/7207174/355/content/browser/renderer_host/navigation_request.cc
Furthermore, although it might increase the code complexity in the renderer side, another option could be to pass a mojo remote via CommitNavigation specifically to receive the PreparedCodeCacheBackendsPtr. This approach would allow us to avoid blocking (deferring) the navigation even if the ShareReadOnlyConnection hasn't completed by the time of the navigation commit.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |