GitLab

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}