| Age | Commit message (Collapse) | Author |
|---|
|
Exercises a separate code path that stores some JS objects
outside of JS. Needed before re-writing some other portions
of the JS_Defines.h code.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/943783002
|
|
On origin/master, we only have .ppm format support, so the
expected output files would take up a lot of space. Hence,
this may not get going until XFA hits with its .png
support.
Nor is there a good way to diff these; XFA provides this
for .png as well.
But this will provide at least one automated test to ensure
that we've got non-blank output, at least for one trivially
simple case.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/926173002
|
|
Along the way, I rename some functions in pdfium_test.cc to
match the style guide's FunctionName() syntax, adding
"Example" to make them obviously different from the PDF
internal code with similar name fragments.
The purpose is to at least have some coverage for the
setter/getter macros from JS_Define.h
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/928573002
|
|
Top level script driver for testing/resources/javascript.
Converts each input template file in that directory to a
.pdf file in the working directory (typically
out/Debug/gen/pdfium/testing/resources/javascript), invokes
pdfium_test on it to generate , and crudely diffs the
expected output.
We can now remove generated .pdfs from source control,
keeping only the hand-editable .in templates.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/912803004
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/908023003
|
|
This is a plan for testing JS inside of pdf files under pdfium:
Communication of results will be done via app.alert(), rather than
console.println(), since the latter is not hooked up to any API
callbacks.
pdfium_test.cc is modified to be more careful about use of stdout/stderr,
so that only the app.alert() and the unsupported feature callback use
stdout. Diffing stdout against ..._expected.txt files gives the result.
I added a /javascript directory to separate these from the embeddertest
resources.
The alert callback is backported from XFA. This was an omission.
BUG=https://code.google.com/p/pdfium/issues/detail?id=62
R=jam@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/872103003
|
|
Handles the case of this malformed PDF without crashing. Note that to
get a reproducible test case, a small fix is applied to our .py script
which results in some whitespace/numbering difs across the resources
(down the road, we ought to generate them on the fly in an intermediate
directory).
BUG=454695
R=jun_fang@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/895933003
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=113
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/880043004
|
|
BUG=452455
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/887063003
|
|
These reproduce under pdfium_test with a scale factor < 1.0. Add
them to the repository now for the sake of posterity, even if we
are not automatically testing them.
BUG=451265
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/869923003
|
|
Original Review URL: https://codereview.chromium.org/878333003
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/884873002
|
|
This was fixed by https://codereview.chromium.org/743263002, but the
bug remained open due to confusion.
BUG=https://code.google.com/p/pdfium/issues/detail?id=57
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/878523003
|
|
A suitably corrupted file can cause the parser(s) to repeatedly re-read
sections of the file at increasing parser recursion depth until the
stack is exhausted. There is supposed to be a check for this based upon
the parser "level", but not all call paths pass or update the level as
required.
Much as I hate per-class statics, this introduces one to track the depth
so that the check is enforced no matter how screwy the call path might be
that leads the parser to re-enter itself. This is more palatable than trying
to find all these paths and fix them. We know this is OK since there is
only one thread in here modifying the static.
BUG=451830
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/875263002
|
|
We are making checks in the incorrect order. Also adds two test
cases, one for the this crash, and another for the original issue
that motivated the patch.
Original Patch by Bo at https://codereview.chromium.org/866003003/
BUG=450871
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/872563002
|
|
This also adds a fpdfdoc_embeddertest.cpp to keep the test
file name matching with the API call under test.
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/812933004
|
|
Follow-on work from patch at https://codereview.chromium.org/845643008. This
incorporates that patch, plus adds tests for it and similar conditions. A few
changes are introduced to correct expected behaviour.
This also incoprorates Deepak's fix in https://codereview.chromium.org/845643008/
This incorporates a formerly unlanded tool to generate small valid PDF
files from template input, which is needed to cover all the error cases
here. See https://codereview.chromium.org/791993006/
BUG=450133
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/837723009
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=62
R=jam@chromium.org
Review URL: https://codereview.chromium.org/827733006
|
