4e9dea8d3d
Currently PDFium SDK determines whether to use Skia renderer in the renderer process, and it's determined by feature flag (it's a choice made by either the user or the finch experiment). An enterprise policy will be created to also control the decision on whether to use Skia renderer. Therefore the decision point needs to be moved into the browser process. This CL moves the feature flag check to the browser process before the PDF plugin is created, and sends a `use_skia` flag through the mime handler together with other PDF plugin attributes, so that the logic of checking enterprise policy can be added in the browser process in the future. Bug: 1440430 Change-Id: I8b74d493576f62be6231b872aec4018e7627a3b7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4481627 Reviewed-by: Sam McNally <sammc@chromium.org> Commit-Queue: Nigi <nigi@chromium.org> Reviewed-by: Matthew Denton <mpdenton@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#1141525}
//pdf contains the PDF plugin, its Blink-based replacement, as well as PDF
utility functions that leverage PDFium. It can use low-level components that
live below the content layer, as well as other foundational code like
//printing. It should not use //content or anything in //components that
lives above the content layer. Code that lives above the content layer should
live in //components/pdf, or in the embedder. All the code here should run in
sandboxed child processes.
TODO(crbug.com/1220865): Remove existing //content dependencies.