Switch all includes of base/strings/string_piece_forward.h to use
string_piece.h instead, except in string_piece.h. This will make
reduce potential churn when deleting string_piece_forward.h.
Bug: 691162
Change-Id: Icd204f97f574e764b46ebfba32bce7b742a2cacd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5009848
Commit-Queue: Lei Zhang <thestig@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1221311}
After the Cast convergence project, the file is generic to all Cast
implementations, not just Chromecast.
Generated with:
tools/git/mffr.py -g "*.gn" -g "*.gni" -g BUILDCONFIG \
'build/config/chromecast_build\.gni' 'build/config/cast.gni'
No-Presubmit: True
Bug: 1294964
Change-Id: Ia50a6287a4eb7c822eec78361ce9e5ccbc8035e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5002469
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1220521}
When viewing a PDF, if text is selected, it will remain highlighted
after rotating the page or toggling the 2-up view to ensure that the
text remains selected in the completed page layout.
Bug: 1420684
Change-Id: Ic3de70e543c7efd2370c00fc5cf4d59fc807ba11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4940462
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1210558}
Enabling MiraclePtr in the renderer process surfaced a transient
dangling pointer between two members of `PdfViewWebPlugin`.
This can be seen by running the `browser_tests` suite on
`linux-chromeos-rel` in these two tests:
* `PrintBrowserTest.MultipagePrint`
* `SitePerProcessPrintBrowserTest.MultipagePrint`
Bug: 1444624
Change-Id: I4b16db941f7f46276f605927dcc287f7534defe0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4918733
Reviewed-by: Nigi <nigi@chromium.org>
Commit-Queue: Kalvin Lee <kdlee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1207453}
Currently, calling PDFiumRange::GetScreenRects() can trigger a PDFium
page load, which can have surprising side effects. Prevent this from
happening by ensuring the page is loaded in the PDFiumRange ctor, and
use the existing PDFiumPage::ScopedUnloadPreventer mechanism to prevent
page unloads while PDFiumRange is alive.
To make this work, update PDFiumPage::ScopedUnloadPreventer so it is
public, and make it copyable. Add a unit test to make sure copying
ScopedUnloadPreventer works as expected.
Bug: 1483194
Change-Id: I66b6050258b7f359982c9b73762f0dc0e64e0ed7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4875506
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198572}
paper_size_in_css_pixels can be removed because default_page_description
already contains the page box size.
print_content_area_in_css_pixels can be removed because the page area
can be deduced by subtracting the margins in default_page_description
from the page box size. The page area offset part of this field was
always set to 0,0 in PrintRenderFrameHelper, by the way.
Change-Id: Ib0d32b1089ff0e3e699fafa453f48b1228959c36
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4858744
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1195892}
Let Blink handle the scale factor set in PrintParams. The PDF plug-in
already does this, but Blink didn't. Therefore there was logic in
PrintRenderFrameHelper to determine whether the scale factor should be
applied or not. This can now be removed, since everyone (i.e. PDF and
Blink) is now able to honor blink::WebPrintParams::scale_factor.
The only scaling that PrintRenderFrameHelper now needs to deal with, is
the fit-to-page scale factor, i.e. when the page size specified in CSS
is larger than actual paper.
Add a bunch of browser tests for this. Test coverage was/is really low!
Also test all three scaling mechanisms, when combined: PrintParams
scale, Blink scaling (to prevent inline overflow), and
PrintRenderFrameHelper fit-to-page scaling.
Bug: 1480270
Change-Id: I163486eb0aa0fa2d3d630827394b19a2f97cdaf1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4853339
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1195404}
This is a reland of commit 5208eafb23.
Fixed the build issue by moving the definition of
`TestPdfAccessibilityTree` out of BUILDFLAG(ENABLE_SCREEN_AI_SERVICE)
and wrapping only necessary class functions and members with the
buildflag.
Original change's description:
> Extract high quality images from PDF only when they are needed for OCR.
>
> 32-bit bitmaps with highest available quality are extracted from PDF
> files when they are loaded, so that they would be sent later to OCR
> service. To avoid the memory overhead of this process, this CL
> postpones image extraction to the time they are sent to OCR service,
> and destroys the extracted images immediately after that.
>
> AX-Relnotes: n/a
> Bug: 1471392
> Change-Id: Id337edf693d8d4a4ddd1a56d814a0d1f0e1ac5e4
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4754282
> Auto-Submit: Ramin Halavati <rhalavati@chromium.org>
> Reviewed-by: Kyungjun Lee <kyungjunlee@google.com>
> Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
> Commit-Queue: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1182463}
Bug: 1471392
Change-Id: I1762da4b5d5895ce112f62d0ca99c23236a6135d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4775300
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Commit-Queue: Kyungjun Lee <kyungjunlee@google.com>
Cr-Commit-Position: refs/heads/main@{#1182838}
32-bit bitmaps with highest available quality are extracted from PDF
files when they are loaded, so that they would be sent later to OCR
service. To avoid the memory overhead of this process, this CL
postpones image extraction to the time they are sent to OCR service,
and destroys the extracted images immediately after that.
AX-Relnotes: n/a
Bug: 1471392
Change-Id: Id337edf693d8d4a4ddd1a56d814a0d1f0e1ac5e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4754282
Auto-Submit: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Kyungjun Lee <kyungjunlee@google.com>
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1182463}
To get maximum OCR quality, we need to send the images in the PDFs
with highest available quality.
To do so the image transform matrix is reset to no-scale before getting
the bitmap and reverted after it.
Bug: 1466774
Change-Id: I44b47aef85a03fdaea5ae8f73ab9f88b71c9b08a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4719985
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nigi <nigi@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Auto-Submit: Ramin Halavati <rhalavati@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1177352}
Only sends attachment information to the front end when feature
`kPdfPortfolio` is enabled. This helps put future UI development for
PDF attachment behind the feature flag.
Also parameterizes PdfViewWebPluginWithDocInfoTest so that it can
check if attachment information is sent or not based on whether
`kPdfPortfolio` is enabled.
Bug: 177188
Change-Id: I88be529371532f739319472915f91e32f015c185
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4698674
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1172560}
Add PDF feature "PdfOopif" and flag "pdf-oopif". The intended use is to
be able to switch between using a MimeHandlerViewGuest or an OOPIF to
launch the PDF Viewer.
Bug: 1445746
Change-Id: Ifeaf2bcc66ecf6ac112aa46d97b6237fcd7e4f34
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4666784
Commit-Queue: Andy Phan <andyphan@chromium.org>
Reviewed-by: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1171407}
When an image is added to the GpuImageDecodeCache, it is never removed
until the cache is cleared or it runs out of capactity. The capacity is
set on the renderer side to 2000 images by default. Howver, the actual
caching happens in the GPU process, in the service transfer cache (for
the most common path). There, the capacity is set to 256MiB on most
desktop machines, and 128MiB on Android. So overall, once an image is
added to the decode cache, it is not removed until memory usage reaches
256MiB on desktop.
However, for PDF rendering, a brand new image is produced by the plugin
at each frame, and never re-used. This means that at 1080p, each frame
adds ~8MiB into the cache, filling it up after 32 frames.
Since we know that the images are never re-used, this CL addresses that
by setting a "no_cache" flag on the cc::PaintImage, which prevents
caching. Locally, this avoids a 256MiB memory spike when scrolling a
PDF. For more details, see the linked bug.
Change-Id: Ic27238784ed3fabbdf63a5f337e32735e5fe62e5
Bug: 1464610
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4683446
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Reviewed-by: K. Moon <kmoon@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1171231}
This is a reland of commit 747748b355.
This CL removes the extra line in
tools/metrics/histograms/enums.xml.
Original change's description:
> Create a feature flag for PDF portfolio
>
> Creates a feature flag `pdf-portfolio` which will be an indicator that
> portfolio feature is enabled in the PDF viewer. Currently this flag is
> a dummy flag that has not been linked to the actual feature yet.
>
> Bug: 177188
> Change-Id: Ief14cbdad785bad405bf402d3cb57b22314a07c1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4651500
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Commit-Queue: Nigi <nigi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1164297}
Bug: 177188
Change-Id: I5c37624ad198ec0a6f7efdfbbeb4d2f4c928fb08
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4661237
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1167665}
Creates a feature flag `pdf-portfolio` which will be an indicator that
portfolio feature is enabled in the PDF viewer. Currently this flag is
a dummy flag that has not been linked to the actual feature yet.
Bug: 177188
Change-Id: Ief14cbdad785bad405bf402d3cb57b22314a07c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4651500
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1164297}
Use CSS pixels where we can, most prominently, in WebPrintParams.
Convert directly from device pixels to CSS pixels. We used to convert
from device pixels to points, then pass this to Blink, and Blink would
convert it to CSS pixels. The fact that this conversion was
taking place wasn't exactly obvious. The values were multiplied by
PrintContext::kPrintingMinimumShrinkFactor, which was documented as a
somewhat mysterious factor, that, according to the documentation, used
to be 1.25, but more recent research had shown that 1.33333 was a better
factor. But there's really nothing magical or heuristic about this.
There are 96 CSS pixels per inch, and there are 72 points per inch.
96/72 = 4/3 ~= 1.33333
Don't expose internal Blink scaling (remove WebLocalFrame::
GetPrintPageShrink()). Blink sometimes scales down content to fit more
content in the inline direction (as an attempt to avoid clipping and
thus losing content). Take care of that internally, which is more
consistent. Blink used to do it internally for web tests
(SpoolPagesWithBoundariesForTesting() in WebLocalFrameImpl), whereas for
printing in actual Chrome, it was done on the outside, by
PrintRenderFrameHelper::PrintPageInternal().
This also improves media query evaluation "for free". We used to perform
some strange conversions in PrepareFrameAndViewForPrint::
ResizeForPrinting(). The input size used to be in points, and then we'd
*divide* the height (but not the width!) by 1.333, and then pretend that
the result was in pixels. Now that "everything" is in pixels, things
will improve automatically, unless we make an effort to prevent it. It's
still not quite right, and this CL isn't about that anyway (added TODO).
Also update the header/footer template. PrintHeaderAndFooter() used to
cancel out scaling, including the internal 1/1.333 (3/4) scaling in
Blink, so that content in headers and footers would appear 1.333 (4/3)
times as large as it should be. This has now been untangled and cleaned
up, so we need to ask for the sizes we actually want to see, rather than
3/4 of that. This includes the options passed to
setupHeaderFooterTemplate(). setupHeaderFooterTemplate() specifies the
page size in pixels, although it was actually passed in points. But that
looked just fine, since everything was accidentally (?) zoomed in by
4/3.
There was some confusion on the web tests side of things.
PrintFrameToBitmap() thinks that it takes a page size in pixels, but
this value was multiplied with 1.333 inside Blink afterwards, so it was
effectively points, not pixels. We need to rebaseline or rewrite quite a
few of the tests before we can remove it, so, for now, keep the magical
1.333 scaling thing for tests. Will follow up with a CL that removes
this and rebaselines / rewrites the tests that need it.
Four tests still need to be rebaselined in this CL, though. The
down-scaling of content inside Blink produces slightly different results
now. Since we're using pixels instead of points, and they are passed as
integer values, we end up with a slightly different aspect ratio, so
that LocalFrame::ResizePageRectsKeepingRatio() doesn't behave exactly
like before. Since this CL fixes some rounding errors, two layout tree
dump tests also need to be rebaselined.
Added a few browser tests, both for crbug.com/1444579 (which was the
main motivation for making this change), and also for crbug.com/1117050
since media query evaluation has improved, because we're now using CSS
pixels.
Two of the new tests are disabled. Since we don't support fractional
page sizes, and round down everything to the nearest integer (e.g.
123.9px -> 123px), content that the author would expect to fit on one
page will fragment. Will deal with this in a follow-up.
Bug: 1444579, 1117050
Change-Id: I076cc9f84591b74925465e364ef2f5f4908bb794
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4567866
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1161059}
We were passing offsets and sizes as integers. Use floats instead. In
some parts of the code, sizes and offsets are in CSS pixels, in other
parts they are in device pixels, and in some other parts they are in
points. There are reasons for this, although it's currently a bit more
convoluted than it has to be.
Converting between them was done carefully with integer arithmetic and
some special rounding code. This has worked mostly fine, but is fragile.
I'm working on a CL that straightens out the conversions, to use CSS
pixels instead of points in the Blink APIs (since that's what Blink uses
internally). This would however mean that, if we were to keep on using
integers, rounding errors that used to occur when printing HTML with
Blink would be fixed, but, at the same time, we'd introduce new rounding
errors when printing with a plug-in (when opening a PDF and printing
it), since that part of the code wants things in points.
So use floats to avoid this. This also allows for removal of
PrintParamsWithFloatingSize. Although floats have precision issues for
large integer values, this shouldn't be a problem here, since all the
values changed are about page sizes, or offsets into a page (margins,
unprintable area, etc.). Floats have 23 bits for the integer part, so
as long as we stay (way) below a million pixels / points / whatever,
we're good. It would easily become a problem if we start using floats
for offsets into documents, though, as documents can become very tall.
This CL isn't expected to make much of a behavior difference on its
own. We'll still round down sizes to the nearest integer when entering
Blink HTML layout, since we cannot reliably print fractional page sizes
anyway. Furthermore, the way LocalFrame::ResizePageRectsKeepingRatio()
is used to magically convert from points to pixels is inaccurate, and
still causes the symptoms described in crbug.com/1444579
But it should now be more straight-forward to fix such issues without
introducing new ones.
Change-Id: I5fc5afeb14e5470faf970c9f7c94d0fad243ce3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4604506
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1160870}
Hold unique_ptr<> to chrome-specific subclasses of PDFium public API
types so that their now non-trivial destructors will run and clear
dangling counts when BRP is enabled.
Bug: 1451541
Change-Id: I5a116eb1eb0edd457fead1f345f9b72b5d4f65a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4590416
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1153507}
This DCHECK() makes an assumption about PDFium behavior that is not 100%
correct, so it occasionally fails. Just remove it as failing the
DCHECK() does not affect the rest of the method.
Bug: 1277301
Change-Id: Ic318af014112fde60166c63dd0708ebbe84f72f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4549669
Reviewed-by: K. Moon <kmoon@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146755}
Remove the TODO comments regarding chromium:1440430 for
IsPDFDocTagged(), GetPDFStructTreeForPage() and GetPDFPageSizeByIndex()
since their remaining use cases are only in test environment and the
Skia already have test coverage through field trial.
Bug: 1440430
Change-Id: Ifea5458fd221eaf7590ab4427592caf1b6d88c09
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4548365
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146711}
This CL adds a new method `SetUseSkiaRendererPolicy()` to mojom
interface `PdfToEmfConverter` so that the enterprise policy regarding
whether to use Skia as the PDF renderer is set immediately once the
mojom remote is bound.
This change also sets the enterprise policy from the last instance of caller of chrome_pdf::GetPDFDocInfo(), therefore remove the TODO
comment for chrome_pdf::GetPDFDocInfo().
Bug: 1440430
Change-Id: I2ab78a76447d2566f596fd078e9f655e1006bbe4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4540682
Reviewed-by: Chris Bookholt <bookholt@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146679}
This CL adds a new method `SetUseSkiaRendererPolicy()` to mojom
interface `PdfThumbnailer` and `PdfToPwgRasterConverter` so that
the enterprise policy regarding Skia as PDF renderer is set as soon as
the remote is bound to the printing service.
Bug: 1440430
Change-Id: I16efed03674b20f7601ca5e3fe91b467e99a454f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4533928
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1145082}
This CL sets a global enterprise policy variable from callers of
`chrome_pdf::ConvertPdfPagesToNupPdf()` and `chrome_pdf::ConvertPdfDocumentToNupPdf()` before they are called, so
that `ScopedSdkInitializer()` can initialize PDF SDK based on the enterprise policy.
- Adds a new method `SetUseSkiaRendererPolicy()` to `PdfNupConverter`
so that the policy value can be passed from the browser process to
the printing services.
- Adds a global variable `g_use_skia_renderer_enabled_by_policy` in
pdf.cc so that it can store the enterprise policy status and be used
by `ScopedSdkInitializer()`.
- Adds TODO comments for `ScopedSdkInitializer()` direct callers which
still need access to the enterprise policy values.
Bug: 1440430
Change-Id: Iac1c75906c3ab304d6ec396de3c5d3b2f196ee98
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4529206
Commit-Queue: Nigi <nigi@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1144845}
In http://review.skia.org/687639, many SkSurface static methods
were moved and one was deleted (SkSurface::MakeRasterN32Premul).
This changes the calls in Chromium to match those moved functions.
There should be no functional difference and everything was done
pretty mechanically (e.g. find and replace, regexes, git cl format).
Bug: skia:13983
Change-Id: Iffbfae6b03bd002fe833ae994089318b051b0d43
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4518554
Commit-Queue: Kevin Lubick <kjlubick@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1143250}
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}
- Avoid calling FPDF_InitLibraryWithConfig() a second time in
PDFiumTestBase::SetUp() by moving InitializeSDK() from
FormFillerJavaScriptTest's ctor into SetUp().
- Make InitializeSDK() take an extra parameter `use_skia`. This
enables FormFillerJavaScriptTest to use GetParam() to switch
between AGG and Skia renderer for testing.
Change-Id: Ibbe440700826242e0491e3394e968521a9aa45a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492837
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nigi <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1139257}
On an AXMode change, trigger LoadOrReloadAccessibility() in
PdfViewWebPlugin to rebuild the PDF accessibility tree. When receiving
an AXMode for PDF OCR, PdfOcrService will be created and used to
extract text from images. When receiving AXMode without PDF OCR flag (possibly when the user turns off PDF OCR), the PDF accessibility tree
needs to be built again without OCR results.
This CL enables ChromeVox users to navigate PDF content without
refreshing a PDF tab after turning on PDF OCR. PDF accessibility tree
will be rebuilt when the user chooses to run PDF OCR always or once
and then become available to ChromeVox.
For more information about running PDF OCR always or once, please visit
the design deck in the following go link: go/pdf-ocr-ui
AX-Relnotes: n/a.
Bug: 1393069, 1439865
Change-Id: Id85896be2ba72bdb797c1d4e3e612c91bf2b2552
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4461514
Reviewed-by: K. Moon <kmoon@chromium.org>
Commit-Queue: Kyungjun Lee <kyungjunlee@google.com>
Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1137918}
