
ScopedSdkInitializer has an IsSDKInitializedViaPlugin() call that assumes the call can return true, and skip SDK initialization. This may have been possible about a decade ago, but modern //pdf code separates the two types of use cases, as enforced by `public` headers in //pdf/BUILD.gn: 1) Blink plugin code only run in PDF renderer processes, via //pdf/pdf_view_web_plugin.h. 2) Various utilities only run in service processes and tests, via //pdf/pdf.h. As such, ScopedSdkInitializer is only used in //pdf/pdf.cc, so it only has to deal with uses cases of type (2). Without any type (1) overlap, IsSDKInitializedViaPlugin() should always return false. Change-Id: Idff67d6283d8f6229c5d3e84c7c72f4cd799cce7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5395192 Commit-Queue: Lei Zhang <thestig@chromium.org> Reviewed-by: Andy Phan <andyphan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1278456}
//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.