733e70c328
Send the correct "final update" value, with a test case to trigger the failing scenario. While trying to reduce the number of messages sent while performing find-in-page in crrev.com/1021347, the "final update" bit got set incorrectly and got sent twice in some cases. This causes the browser to "hang up" after receiving the first "final update" message and ignore the second one. Developer builds also trigger a DCHECK() failure when this happens. Fix this by giving the plugin more control over the "final update" bit in the blink::WebPluginContainer::ReportFindInPageSelection() interface, and make the simple change in WebPluginContainerImpl() to pass the value along. Then add all the plumbing necessary to the PDF plugin code to communicate with WebPluginContainer, and let PDFiumEngine::SelectFindResult() send the appropriate values. Bug: 1352097 Change-Id: I91c1433792f0f931258fb893954180f8af1c5f5b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3828901 Reviewed-by: K. Moon <kmoon@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Reviewed-by: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/main@{#1037259}
//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.