The highlighter color options have an opacity of 1, when the actual
brush color has an opacity of 0.4f. Take into account the transparency
in the visible color option by transforming the actual highlighter color
using the alpha blending formula with a white background.
This is purely a presentational change in the UI.
NO_IFTTT=New IFTTT, did not change original value.
Bug: 351868764
Change-Id: Ic4445ed1c7e13d4c7ca33ad4c0c3c2e2ac8dd607
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5840546
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Commit-Queue: Andy Phan <andyphan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1352288}
When the frontend asks the backend to (re)generate the PDF thumbnail,
also generate the Ink thumbnail for the same page if it exists. This
makes the Ink thumbnail render correctly if the frontend cleared the
previously generated thumbnails for some page.
Implement this by taking PdfViewWebPlugin::UpdateThumbnail() and
splitting the relevant part out as GenerateAndSendInkThumbnail().
Then call GenerateAndSendInkThumbnail() in SendThumbnail().
Bug: 353942908
Change-Id: Ib004b2d9d3af4050a74cafafe9c865e59cd4a3ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5838007
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Andy Phan <andyphan@chromium.org>
Reviewed-by: Alan Screen <awscreen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1351738}
PDFs now get non-embedded fonts via a skia/mojo proxy
rather than using "direct" access via sandbox hooks &
sandbox IPCs.
This CL removes the WinPdfUseFontProxy feature and
associated plumbing content code for allowing access to the
local fonts dir.
Bug: 344643689
Change-Id: Idbb5a9ef2e6c24a4f1c08c6505437c9ca1696096
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5805910
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1351684}
PdfInkModule will notify PdfViewWebPlugin that a thumbnail update is
necessary when the following events occur:
- Drawing stroke finishes
- Erasing stroke finishes
- Undo
- Redo
Then PdfViewWebPlugin will get the thumbnail size from the PDF engine,
generate a transparent thumbnail with the Ink strokes, and send that to
the frontend. The frontend can then overlay this thumbnail on top of the
thumbnail for the page contents. With two thumbnails, the relatively
static page contents thumbnail does not need to be repeatedly
regenerated.
Bug: 353942908
Change-Id: I4adaac90d3c15aa723d42bfb9e9b95d0b7d77828
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5824214
Reviewed-by: Alan Screen <awscreen@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Andy Phan <andyphan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1351607}
- Add MouseEventBuilder::CreateLeftMouseUpAtPosition() and use it where
applicable.
- Add PdfViewWebPluginTest::TestSendInputEvent() and simplify test cases
that send input events and maybe check the cursor after.
Change-Id: I0fe9b1adfa0e69828962501cd069b66308f7b1a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5839558
Reviewed-by: Alan Screen <awscreen@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1351602}
When the feature flag is enabled, extracts the PDF bytes from the PDF
renderer process and sends them to the Lens server to help with
contextualization. This CL is meant to help prototype and unblock server
side work, not be used on any real users yet. Therefore the logic is
gated by a feature flag defaulted to off. Bytes only leave the device if
the user invokes the Lens Overlay after manually turning on the feature
flag.
Before enabling the flag for real users, updates will be made to our
privacy data notice so no bytes leave the device unless the user
consents.
More info in the design doc linked in the bug.
Bug: 361409401
AX-Relnotes: n/a.
Change-Id: I9c261fe4e02a607a845bcef6bb2375830880ff37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5811891
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Duncan Mercer <mercerd@google.com>
Reviewed-by: Jason Hu <hujasonx@google.com>
Cr-Commit-Position: refs/heads/main@{#1350343}
This uses the same approach as https://crrev.com/c/5818311 to record
find-in-page actions to the PDF.Actions histogram. This gives better
insight into which features are being used in the PDF Viewer.
Here, the feature is triggered by the browser's frontend, which then
talks to the PDF Viewer's backend and bypasses the PDF Viewer frontend.
To record these actions, the backend has to send a simple message to the
frontend.
Bug: 350222373
Change-Id: I563e70bd8b7e00eda804db5ec3a287ebdb53a255
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5823641
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Alan Screen <awscreen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1348769}
The PDF.Actions histogram is incomplete and does not show how often
users interact with text in PDFs via cut/copy/paste. Add new histogram
enum values to record these actions.
Unlike most existing actions that are initiated in the PDF Viewer's
frontend and recorded there, cut/copy/paste take place in the backend.
To record these actions, the backend has to send a simple message to the
frontend.
Along the way, update the owners for PDF.Actions, and add the enum
values from https://crrev.com/1178835 which are missing in enums.xml.
Bug: 350222373
Change-Id: I6c9c554640e77b181a7df25e676b1d53f898a542
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5818311
Reviewed-by: Alan Screen <awscreen@chromium.org>
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1348705}
Given the following code snippets:
void Foo(Enum e) {
switch (e) {
case ...:
...
return;
}
}
int Bar(Enum e) {
switch (e) {
case ...:
...
return val;
}
}
If the switch statements do not have a default case, since all defined
enum values are handled, then undefined enum values can cause undefined
behavior as suggested in https://abseil.io/tips/147. Avoid this by
guarding the UB code path with NOTREACHED().
Clang actually generates "ud2" instructions in debug builds in the
places where this CL adds NOTREACHED(). Whereas in release builds, Clang
does whatever it wants.
Also do IWYU for base/notreached.h in this directory.
Change-Id: I4bbfe8ed091627608bc84f9658fe2c01dc47fec1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5813603
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1347070}
NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
Bug: 40580068
Low-Coverage-Reason: OTHER Should-be-unreachable code
Change-Id: I0d9e7d1dc3324cdb0fd4b3ce3ce9a7ee2c6079ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5802701
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1346787}
Avoid the use of "page number", which is oftentimes considered 1-based.
Consistently use the "page index" terminology, which makes it clearer
that the values are 0-based.
Change-Id: I3c29b56b759731371881d730c8a5dc307c773b8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5791835
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1342900}
Per the updated unsafe_buffers.md, UNSAFE_BUFFERS() should only
be used for cases where subsequent spanification is not possible, and
that other cases should use the UNSAFE_TODO() macro.
Then update existing usage to conform to this convention. Code lacking
safety comments is converted to UNSAFE_TODO() as well.
Document some functions that should propagate unsafety to their
callers via UNSAFE_BUFFER_USAGE but do not enforce this.
Change-Id: Ieb6472102a2e245d040b4d4ad50317c2358d9783
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5786346
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1342098}
NOTREACHED() has turned [[noreturn]] so the former macro isn't needed
anymore.
This does not attempt to do a rewrite of any surrounding code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
NO_IFTTT=No-op-rename migration.
Bug: 40580068
Change-Id: I068c5fdce9dc4c352d8bdd62bb3cd2c0a2d59659
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5782602
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1342096}
Make WinPdfUseFontProxy on by default in M129. A flag
(pdf-win-use-font-proxy) exists for users to toggle this
until it is removed.
Bug: 344643689
Change-Id: I8accdf7eba2c3ac0bf2a5dbfddb597afe2647066
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5754127
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1335817}
Now that FPDFText_GetTextObject() exists, many existing FPDFText_* API
calls inside pdfium_page.cc can be replaced with an equivalent
FPDFTextObj_* API call, or FPDFFont_* API call:
FPDFText_GetFontSize() -> FPDFTextObj_GetFontSize()
FPDFText_GetFontInfo() -> FPDFFont_GetBaseFontName() and
FPDFFont_GetFlags()
FPDFText_GetFontWeight() -> FPDFFont_GetWeight()
FPDFText_GetFillColor() -> FPDFPageObj_GetFillColor()
FPDFText_GetStrokeColor() -> FPDFText_GetStrokeColor()
Make these conversions and add more error checking as needed, to clear
the way for removing these FPDFText_* APIs from PDFium.
As part of the conversions, many functions that take the pair
(FPDF_TEXTPAGE, int /*char_index*/) can be simplified to just take
FPDF_PAGEOBJECT. Do this recursively to simplify more related code.
Bug: 353746891, 353746892
Change-Id: I846093a8ee5979415eefa2121936c3ba81b08c49
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5719478
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Alan Screen <awscreen@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1333795}
Most of the time, the mouse up event has the same position as the most
recent mouse move event. However, this is not always the case and the
position may be different. Handle this possibility by processing the
mouse up event like it was also a mouse move event at the same position.
When drawing, this can now frequently trigger a condition where the
mouse position did not change between two calls. For this case, treat
mouse move events where the position did not change from the last
position as no-ops.
Then update all the unit tests to account for this new behavior.
Bug: 335524380
Change-Id: I5f332fe2082e95343623dada65ad9cff73bc52ff
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5726894
Reviewed-by: Alan Screen <awscreen@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Andy Phan <andyphan@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1332438}
OCR needs at most 300 DPI images. `chrome_pdf::GetImageForOcr` is
updated to reduce its output size if the image has higher resolution.
Bug: 353445502
Change-Id: I5601bc2cf6358df0f7b7a00230ee157c55677735
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5718048
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1330904}
PdfAccessibilityTree gets the page and image index of the images in PDF
and stores them in OCR requests, and later fetches the images when OCR
is ready to process them.
PDFs are generated dynamically in print preview mode and the indices may
change during accessibility tree generation and OCR steps.
To fix the issue OCR is now disabled in Print preview, and will be
supported later in PDFium layer.
AX-Relnotes: Unlabeled images are not OCRed in print preview.
Bug: 353205017
Change-Id: If599784531041bf614a0fc768f8aae3f46fd38fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5720529
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: David Tseng <dtseng@chromium.org>
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1330269}
Page orientation is passed to PdfAccessibilityTree and is applied to the
bounding rects generated by OCR.
AX-Relnotes: If user rotates a PDF, OCR generated text boundaries are also rotated.
Bug: 40918374
Change-Id: I74b9a7c5c5137ff0e07124036d3e2672d20912b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5701644
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Ramin Halavati <rhalavati@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1330020}
