b3bff9f439
To avoid running out of memory, get data from the plugin and save it in
maximum 16MB blocks. The process is done as follows.
1. Viewer asks for the suggested file name from Plugin.
2. Viewer shows the file picker user interface to the user and opens
the selected file.
3. Viewer asks Plugin for file content.
4. Plugin returns the file content, capped at 16MB limit. It also sends
the total file size.
5. Viewer writes the data to the file.
6. If the returned data is not all of the file, Viewer asks for the
next block of data from Plugin, passing the offset to the beginning
of the next block, and repeats until all of data is received and
saved.
The new approach uses already downloaded PDF data to save original
PDFs and in contrast to the existing approach, does not redownload the
PDF.
Also by removing the memory limitation, the limit on the maximum size
is increased from 10MB to 2GB.
This CL only updates the plugin side, and the UI update is done in
http://crrev.com/c/6362354
Bug: 394111292
Change-Id: I82f16c524a3bdac037f8157242a8e65fa9ccfb83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6252966
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1437328}
//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/40186598): Remove existing //content dependencies.