Age | Commit message (Collapse) | Author |
|
Review-Url: https://codereview.chromium.org/2262703003
|
|
BUG=636559
Review-Url: https://codereview.chromium.org/2255083004
|
|
The PDF specification [1] says:
"
syncAnnotScan guarantees that all annotations will be scanned
by the time this method returns.
(..)
Normally a background task runs that examine every page and
looks for annotations during idle times.
"
The statement details specifically how Acrobat implements
this method.
Although, neither the method itself nor the background scanner
task are implemented in PDFium (as of today, Ago/2016),
not having ::syncAnnotScan at least stubbed out can be considered
harmfull since its absence makes JS acrobat scripts silently
fail when it has a call to it.
Given that, and following a stub-out pattern present in other
methods including ::addAnnot and ::addField, CL provides
a stubbed out implementation of Document::syncAnnotScan.
[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2265553002
|
|
CL implements the first step in order to support
Annotations manipulation in PDFium: Document::getAnnot.
The method takes two arguments, an integer (page number)
and a string (annotation name).
When called, it iterates over the annotations on
the given page number, searching for the one whose name
matches the string in the second parameter.
If found, then an Annot instance (see Annot.cpp/g added by this
CL), is bound to a Javascript object and returned.
With the use cases described in bug [1] as an initial test case,
CL adds support to the following Annotation object properties:
- hidden
- name
- type
Idea is to keep evolving the implementation with more methods
and properties in follow up CLs.
[1] https://bugs.chromium.org/p/pdfium/issues/detail?id=492
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2260663002
|
|
Put class definition into its own header file so fuzzer can find it.
Fix a pair of div by 0s immediately hit by the fuzzer.
Review-Url: https://codereview.chromium.org/2253193003
|
|
Now that PDFium supports drawing of more annotation
types, it should also respect the "hidden" flag that
annotations might feature.
For instance, in IE/Acroread if an annotation is flagged as
"hidden" it does not get drawn.
CL adds a check for the specific "hidden" flag, not drawing
annotation that are flagged with it, in order to match IE + acrobat
reader behavior.
The "flags" definition can be seen by looking at "/F {value}"
syntax in a PDF file source, where {value} is an predefined
integer value.
Test: PDF files being added in [1].
[1] https://codereview.chromium.org/2239713003/
BUG=62625
Review-Url: https://codereview.chromium.org/2239853002
|
|
Nearly all the "loose" functions in FXJS become methods on
the CFJXS_Engine.
This is the "missing link" wrt some layering violatons that
have been around forever. We can stop passing &m_ variables
from CJS_ down into FXJS Initialization as a result.
Review-Url: https://codereview.chromium.org/2245863002
|
|
Create a new class to hold these, CFXJS_Engine (could have been
called Runtime, but there are too many "Runtimes" already). In a
subsequent patch, all the FXJS_*() functions that take an isolate
as the first argument can become methods on the engine.
CJS_ must still manage the isolates; this happens outside
the engine.
The IJS_Runtime abstraction moves up to fpdfsdk/javascript; it
remains to allow for either a real JS library or a stubb one to
be linked (for non-js builds).
Review-Url: https://codereview.chromium.org/2241483004
|
|
As per the PDF specification in [1], page 103, the
'info' property of the Document object is readonly.
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
Review-Url: https://codereview.chromium.org/2235883003
|
|
Patch implements the Document's API gotoNamedDest, which is
part of the PDF specification [1], page 129, with the following
(short) description:
"Use this method to go to a named destination within the
PDF document".
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
"Named destination" is a common concept in the PDF world.
It can be used together with PDF's Links, Annotations, Bookmarks
and OpenActions, as well as an action per se, in case "this.gotoNamedDest"
is called directly.
Note that the implementation makes use of the existing hook
CPDFDoc_Environment::FFI_DoGoToAction, which ends up calling
out the embedder to actually handle it.
In case of Chromium, for instance, it calls PDFiumEngine::Form_DoGoToAction
which only handles for now the "page" property of the "destination".
Other properties, including zoom level, and scroll position
are ignored for the moment.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2221823003
|
|
As per the PDF specification at [1]
"
This property specifies the document's URL.
".
IE/Acrobat supports it, and getting it implemented
would be one step forward in order to support Acrobat JS
script as the one in [2].
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
[2] https://bugs.chromium.org/p/pdfium/issues/detail?id=492
BUG=492
Review-Url: https://codereview.chromium.org/2219183002
|
|
Fix memory ownership model for PDFium timers.
The |app| class owns the CJS_Timer as part of its vector<unique_ptr>
to them.
The CJS_Timer "owns" its slot in the global ID to timer map, and
removes itself when it is destroyed. Nothing else deletes
from the global map. Deleting from the global map is
accompanied by a callback to the embedder to clear its
resources.
Next, the proper way to remove a CJS_Timer is by going
through the app, and having the app erase its unique ptr,
which then deletes the CJS_Timer, which in turn cleans up the
global map. Provide a CJS_Timer::Cancel static method to
do this conveniently.
There is a alternate path to the CJS_timer via JS and its
CJS_TimerObj. CJS_TimerObj owns a TimerObj that currently
points to the CJS_Timer. If the timer fires, and cleans
itself up, this can go stale.
Make the TimerObj maintain a weak reference via global
timer ID rather than a direct pointer to the CJS_Timer, so
that if the timer fires and is destroyed, future attempts
to cancel find nothing.
There is another path, where if the JS timer object is GC'd, then we
just clean up its CJS_TimerObj without touching
the actual CJS_Timers. We could make this match the spec
by calling into the new cancel routine as described above,
but it seems weird to have a timer depend on whether a gc
happened or not.
A subsequent CL will rename these objects to more closely
match the conventions used by the other JS wrappers.
BUG=634716
Review-Url: https://codereview.chromium.org/2221513002
|
|
We must look the timer up a second time since the callback
may have released it.
BUG=634394
Review-Url: https://codereview.chromium.org/2214003003
|
|
Adds more questionable invocations of ClearTimeOut().
Also, checking that nothing happened is fragile. Log at least
one thing to show that the code ran.
Review-Url: https://codereview.chromium.org/2218473002
|
|
While we're at it, beef up existing test for non-cancellation.
In turn, fix test harness to implement intervals properly.
In turn, fix public documentation to be clearer about timers.
Also rename a few identifiers that sounded "off".
Review-Url: https://codereview.chromium.org/2211513002
|
|
The pointer a unique_ptr contains should be checked instead of the
pointer of the unique_ptr itself.
BUG=chromium:631912
Review-Url: https://codereview.chromium.org/2205573004
|
|
This Cl splits out the CXFA_WideTextRead class into it's own file. The helper
methods have been moved into xfa_utils.cpp and their pre-declarations into
xfa_utils.h.
Review-Url: https://codereview.chromium.org/2165993002
|
|
This CL moves the fpdfsdk/sjapi code info fxjs/. The "fxjs" library is moved
from being XFA specific to being compiled if V8 is enabled.
The fxjs_v8 files are required when building for XFA (they have XFA defines
in them) and are used in CFXJS_RuntimeData. The cfxjse_* files are only added
if XFA is also enabled.
Review-Url: https://codereview.chromium.org/2144603003
|
|
This CL splits the three parsers into individual files to make working with
the code easier.
Review-Url: https://codereview.chromium.org/2129963002
|
|
The IXFA_Parser only created a CXFA_SimpleParser, the CXFA_DocumentParser is
only created in one spot and doesn't need all the IXFA_Parser methods.
This CL removes IXFA_Parser, instantiates the CXFA_SimpleParser where needed
and cleans up surrounding code.
Review-Url: https://codereview.chromium.org/2123133004
|
|
And call it from FPDF_DestroyLibrary(). Otherwise further attempts to
FPDF_InitLibraryWithConfig() can hit fail an assertion in
IJS_Runtime::Initialize().
BUG=604587
Review-Url: https://codereview.chromium.org/2103443004
|
|
Review-Url: https://codereview.chromium.org/2068563002
|
|
EmbedderTest::OpenDocument() does not gracefully handle the case of
being called twice in a given test case. So avoid doing that.
Review-Url: https://codereview.chromium.org/2088093002
|
|
This CL adds a fuzzer for the CFX_SAXReader.
BUG=chromium:587126
Review-Url: https://codereview.chromium.org/2070103002
|
|
This CL adds a fuzzer for the CSS Syntax parser in XFA.
BUG=chromium:587126
Review-Url: https://codereview.chromium.org/2068513002
|
|
The progressive decoder will attempt to verify that the provided image type
matches the actual image content. We need to disable this check when running
the fuzzer in order to target the fuzzing to specific decoders otherwise
each fuzzer will end up fuzzing all of the decoders.
BUG=chromium:587126
Review-Url: https://codereview.chromium.org/2061733002
|
|
This pulls in the android NDK and catapult, rolls chromium/src/build/,
and pulls in two .gni updates. It also fixes a few miscellaneous compile
failures in android-specific code.
BUG=pdfium:38
Review-Url: https://codereview.chromium.org/2059553002
|
|
R=machenbach@chromium.org,thestig@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2053603002
|
|
Generalize the PNG fuzzer and add fuzzers for the other image types handled by
the progressive decoder.
BUG=chromium:617659, chromium:616842, chromium:616841, chromium:616839
Review-Url: https://codereview.chromium.org/2045613002
|
|
This CL creates a fuzzer for the CCodec_PngModule code.
BUG=chromium:616838
Review-Url: https://codereview.chromium.org/2047453002
|
|
The entire code base is single-threaded, hence the lockers
ought not be required.
Review-Url: https://codereview.chromium.org/2026933002
|
|
R=thestig@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2019383002
|
|
BUG=pdfium:496
Review-Url: https://codereview.chromium.org/2005653002
|
|
This CL combines the corpus runner into the test_runner.py. This also
enables the javascript and pixel runners to do a multi test runner.
Review-Url: https://codereview.chromium.org/1952923002
|
|
This reverts commit fa34e805fd03ba81bcfe1148cf96b24fe63b39a0.
Reason for revert: broke asan tests.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1982843002 .
|
|
Review-Url: https://codereview.chromium.org/1981003002
|
|
Review-Url: https://codereview.chromium.org/1874773002
|
|
files. (patchset #1 id:1 of https://codereview.chromium.org/1946693002/ )"
This reverts commit a031357eaab7c934ac03717968cf78ff556c819b.
The reason to revert it is that some malformed or maliciously crafted PDF
files may cause crashes.
BUG=610973
Review-Url: https://codereview.chromium.org/1971013002
|
|
data_binding.pdf is much closer now that events are sent.
It still diffs due to some bg color issues, not that the
box is unchecked.
Review-Url: https://codereview.chromium.org/1952823002
|
|
Passing bad args in pdfium_test -- all void* pointers look alike.
Make output less verbose while we're here. Turn on event sending
mode for corups tests. No effect until .evt files added to corpus.
Review-Url: https://codereview.chromium.org/1946873004
|
|
(patchset #1 id:1 of https://codereview.chromium.org/1946693002/ )
Reason for revert:
The culprit was found and confirmed, not this one.
Original issue's description:
> Revert of Relax a couple checks to allow certain non-standard PDF files. (patchset #1 id:1 of https://codereview.chromium.org/1926823002/ )
>
> Reason for revert:
> Speculatively revert due to high volume of crashes on Chromium.
>
> Original issue's description:
> > Relax a couple checks to allow certain non-standard PDF files.
> >
> > Some non-standard PDF files misuse the size of cross reference table,
> > and reuse some object number which the old one is still in use. PDFium
> > can relax the reusing of xref objects only since it is not referred in
> > the pdf document. When the size of cross reference table is larger
> > than defined, PDFium will try to continue other than abort.
> >
> > BUG=chromium:596947
> >
> > Committed: https://pdfium.googlesource.com/pdfium/+/cd1e9ff4f432cbc29ed279e6891fb7ddc2ea3734
>
> TBR=thestig@chromium.org,dsinclair@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=chromium:596947
>
> Committed: https://pdfium.googlesource.com/pdfium/+/5fc4f31285c3a88fc157fd2d9b9cf2eb5c7cabed
TBR=thestig@chromium.org,dsinclair@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:596947
Review-Url: https://codereview.chromium.org/1947983002
|
|
(patchset #1 id:1 of https://codereview.chromium.org/1926823002/ )
Reason for revert:
Speculatively revert due to high volume of crashes on Chromium.
Original issue's description:
> Relax a couple checks to allow certain non-standard PDF files.
>
> Some non-standard PDF files misuse the size of cross reference table,
> and reuse some object number which the old one is still in use. PDFium
> can relax the reusing of xref objects only since it is not referred in
> the pdf document. When the size of cross reference table is larger
> than defined, PDFium will try to continue other than abort.
>
> BUG=chromium:596947
>
> Committed: https://pdfium.googlesource.com/pdfium/+/cd1e9ff4f432cbc29ed279e6891fb7ddc2ea3734
TBR=thestig@chromium.org,dsinclair@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:596947
Review-Url: https://codereview.chromium.org/1946693002
|
|
https://codereview.chromium.org/1923333002/ )
Reason for revert:
Blocking the roll
Original issue's description:
> Allow overriding GN build flags
>
> In order to enable XFA from GN builds we need to be able to override
> pdf_enable_xfa. To do this a build_overrides/pdfium.gni file needs to be created
> in Chrome. To use that, we have to create a build_overrides/pdfium.gni file
> in PDFium that just uses the default values.
>
> BUG=chromium:62400
>
> Committed: https://pdfium.googlesource.com/pdfium/+/1ae572e7e35b52ce4897d1715c005a1b0f79526a
TBR=thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:62400
Review-Url: https://codereview.chromium.org/1941563002
|
|
Some non-standard PDF files misuse the size of cross reference table,
and reuse some object number which the old one is still in use. PDFium
can relax the reusing of xref objects only since it is not referred in
the pdf document. When the size of cross reference table is larger
than defined, PDFium will try to continue other than abort.
BUG=chromium:596947
Review-Url: https://codereview.chromium.org/1926823002
|
|
The corpus tests redirect output to a string but they just output it
later anyway. This CL removes the output redirect and removes the
redirect_output flag which will always be False now.
Review-Url: https://codereview.chromium.org/1927633002
|
|
In order to enable XFA from GN builds we need to be able to override
pdf_enable_xfa. To do this a build_overrides/pdfium.gni file needs to be created
in Chrome. To use that, we have to create a build_overrides/pdfium.gni file
in PDFium that just uses the default values.
BUG=chromium:62400
Review-Url: https://codereview.chromium.org/1923333002
|
|
There are currently three ways to assert in the code (ASSERT, FXSYS_assert and
assert). This CL standardizes on ASSERT. The benefit of ASSERT is that it can
be overridden if the platform requies and we can pickup the Chromium version
if it has already been defined in the build.
This does change behaviour. Currently FXSYS_assert is always defined but ASSERT
is only defined in debug builds. So, the FXSYS_assert's would fire in Release
builds. That will no longer happen.
BUG=pdfium:219
Review-Url: https://codereview.chromium.org/1914303003
|
|
These runners are very similar in their implementation. Combine them into
a single test runner.
Corpus will, hopefully, be combined into this test runner in the future.
Review URL: https://codereview.chromium.org/1906803005
|
|
Without the mac_deployment_target_build_override variable in build.gni
the following error is produced.
ERROR at //build/config/mac/mac_sdk.gni:17:27: Undefined identifier
mac_deployment_target = mac_deployment_target_build_override
^-----------------------------------
Added needed gtest/gtest_mac.* files.
BUG=pdfium:106
Review URL: https://codereview.chromium.org/1907193002
|
|
Some unknown software generates cross reference table with the
claimed object numbers are all off by one. Add a simple verification
function to detect this scenario, thus have a chance to rebuild
the correct cross reference table.
To avoid unnecessary checks and potiential performance hit, we only
check for the very first non free entry.
BUG=602650
Review URL: https://codereview.chromium.org/1910063004
|