Move SiteIsolationPolicy::ShouldPdfCompositorBeEnabledForOopifs from //content to //components
Currently, there are two SiteIsolationPolicy objects: one in //content which knows about content-internal things, and one in //components, which knows about higher-layer modes such as password-triggered site isolation on Android. The ShouldPdfCompositorBeEnabledForOopifs() in content was a bit problematic for two reasons: (1) it's a bit of a layering violation for content to know about PDF compositor, (2) it implicitly relied on AreIsolatedOriginsEnabled() being true for the password-triggered site isolation mode used on Android, which stopped being true in https://crbug.com/1005895. This CL moves ShouldPdfCompositorBeEnabledForOopifs() to the SiteIsolationPolicy in //components, where it's also updated to check IsIsolationForPasswordSitesEnabled() in addition to the other two site isolation modes. Note that this still should exclude (1) low-memory Android devices that don't use any site isolation (enforced via IsSiteIsolationDisabled() checks inside SiteIsolationPolicy), and (2) Android Webview, where OOPIFs aren't supported (hopefully this is true because AW doesn't go through code paths that check ShouldPdfCompositorBeEnabledForOopifs()). Eventually, the goal is to enable PDF compositor everywhere, so hopefully we can remove ShouldPdfCompositorBeEnabledForOopifs() altogether at some point. Bug: 1022917 Change-Id: Ib8d3a7c7b133707d5c6ca88efbbdc0f77635fe1a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2500444Reviewed-by:Wei Li <weili@chromium.org> Commit-Queue: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/master@{#822049}
Showing
Please register or sign in to comment