summaryrefslogtreecommitdiff
path: root/testing
AgeCommit message (Collapse)Author
2016-11-07Fix #include after commit c09625ca.thestig
TBR=tsepez@chromium.org Review-Url: https://codereview.chromium.org/2477323004
2016-11-07Rename CPDF_Linearized to CPDF_LinearizedHeadertsepez
My OCD insists that classes be named after nouns, and "linearized" feels like an adjective. Remove a redundant "if" while at it. Review-Url: https://codereview.chromium.org/2482973002
2016-11-07Reland of Unify some codeart-snake
Unify some code Move parsing of linearized header into separate CPDF_Linearized class. Original review: https://codereview.chromium.org/2466023002/ Revert review: https://codereview.chromium.org/2474283005/ Revert reason was: Breaking the chrome roll. See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856 ___ Added Fix for fuzzers. Review-Url: https://codereview.chromium.org/2477213003
2016-11-07Revert of Compile fuzzer sources in standalone builds. (patchset #3 id:40001 ↵npm
of https://codereview.chromium.org/2480043002/ ) Reason for revert: Breaking the tree: https://build.chromium.org/p/client.pdfium/builders/windows_xfa_32/builds/619/steps/compile%20with%20ninja/logs/stdio Original issue's description: > Compile fuzzer sources in standalone builds. > > - Add a template for fuzzers to remove redundancy. > - Sort fuzzers in alphabetical order. > > Committed: https://pdfium.googlesource.com/pdfium/+/470b5fa8f8dbfd2aa702d9d8cfdc03a7b486b374 TBR=dsinclair@chromium.org,thestig@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2480323002
2016-11-07Compile fuzzer sources in standalone builds.thestig
- Add a template for fuzzers to remove redundancy. - Sort fuzzers in alphabetical order. Review-Url: https://codereview.chromium.org/2480043002
2016-11-04Implement FPDF_VIEWERREF_GetName() API.chromium/2910thestig
This is a generic API function to retrieve any viewer preference of type name. BUG=pdfium:414 Review-Url: https://codereview.chromium.org/2475923003
2016-11-04Reland "Remove CPDF_Object::Release() in favor of direct delete"tsepez
This reverts commit f0d5b6c35fa343108a3ab7a25bc2cc2b3cf105b3. Review-Url: https://codereview.chromium.org/2478303002
2016-11-03Fix roll after TRUE conversiondsinclair
TBR=tsepez@chromium.org Review-Url: https://codereview.chromium.org/2471253004
2016-11-03Remove FX_BOOL entirely.tsepez
FX_BOOL was a type just like a regular C++ bool, except that it took 4x the space and frequently was used to hold values besides true or false. Review-Url: https://codereview.chromium.org/2471353002
2016-11-01libfuzzer: FALSE is not a pointertsepez
BUG=661291 TBR=dsinclair@chromium.org Review-Url: https://codereview.chromium.org/2469923002
2016-10-27Fix libfuzzer build broken at 9f7f7f8tsepez
BUG=660015 TBR=npm@chromium.org Review-Url: https://codereview.chromium.org/2452523005
2016-10-24Rename IFX_ stream nameschromium/2900tsepez
It's been troubling for some time that an IFX_FileStream might actually be an in-memory buffer with no backing file. Review-Url: https://codereview.chromium.org/2443723002
2016-10-18Add a test case for bug 494057.thestig
The expectation is set incorrectly to allow the test to pass. BUG=chromium:494057 Review-Url: https://codereview.chromium.org/2430583002
2016-10-06Fixup MSan embeddertestsDan Sinclair
The embeddertests were closing the document before the formfill environment. This caused a use-after-free as we try to use the document during formfill destruction. This Cl fixes the destruction order in the embedder tests. As well, a few guards are put in place to keep the system from crashing if the wrong destruction order is called. R=tsepez@chromium.org Review URL: https://codereview.chromium.org/2398063002 .
2016-10-04Fix fuzzer pathsdsinclair
Missed these again. Scripting fail. BUG=pdfium:603 Review-Url: https://codereview.chromium.org/2393433003
2016-10-04Make sure the fuzzer read size does not go negative.dsinclair
When fuzzing the image formats, its possible to get a read request which would go negative. Handle the request and return FALSE for the read. BUG=chromium:621836 Review-Url: https://codereview.chromium.org/2386343002
2016-10-04Update test expectations for unexpected successes.thestig
Review-Url: https://codereview.chromium.org/2387333002
2016-10-03Add ptr_util.h from base until std::make_unique<> availabletsepez
Review-Url: https://codereview.chromium.org/2386273004
2016-09-30Fix #includes in libfuzzer so pdfium can be rollednpm
Note: pdfium bots don't seem to touch these files. Review-Url: https://codereview.chromium.org/2379973005
2016-09-29Move fxjs/include to fxjsdsinclair
BUG=pdfium:611 Review-Url: https://codereview.chromium.org/2380713005
2016-09-29Move core/fxcrt/include to core/fxcrtdsinclair
BUG=pdfium:611 Review-Url: https://codereview.chromium.org/2382723003
2016-09-28Replace a few more std::unique_ptr.reset() with WrapUnique assignments.thestig
And fix a typo. TBR=tsepez@chromium.org Review-Url: https://codereview.chromium.org/2382443004
2016-09-27Add fuzzer for jbig2 parsingkcwu
Review-Url: https://codereview.chromium.org/2370943004
2016-09-26Clean up fx_codec_fax.cpp.thestig
Review-Url: https://codereview.chromium.org/2357173005
2016-09-26Add fuzzer for cmap parsingchromium/2873kcwu
Review-Url: https://codereview.chromium.org/2365143002
2016-09-23Bail out on bad width and height in CCodec_FaxDecoder::CreateDecoderkcwu
BUG=648935,649436 Review-Url: https://codereview.chromium.org/2360283004
2016-09-22Add fuzzer for icc codeckcwu
Review-Url: https://codereview.chromium.org/2362623002
2016-09-21Set up isolate in CFXJS_Engine's constructorweili
CFXJS_Engine class should always be constructed with an isolate, except for its subclasses which may need to create an isolate by themselves. Move SetIsolate() function to be protected so that only subclasses can access it. Review-Url: https://codereview.chromium.org/2354353002
2016-09-19Add fuzzer for fax codeckcwu
Review-Url: https://codereview.chromium.org/2342203006
2016-09-15Use either /RECT or /QuadPoints for annotation coordinates, depending on /APtonikitoo
On Acrobat, if "/AP" is present on a text markup definition, the coordinates used to draw the annotation come from "/Rect values, whereas if "/AP" is not defined, the array defined in /QuadPoints is used to grab the annotation coordinates from. PDFium, on the other hand, uses "/Rect" regardless of presence or absence of "/AP". CL fixes PDFium to work similarly to Acrobat, in this case. TEST=testing/resources/pixel/bug_585_*.in BUG=pdfium:585 Review-Url: https://codereview.chromium.org/2289293005
2016-09-15Use ToUnicode mapping even when unicode is 0.npm
CPDF_Font::UnicodeFromCharcode returns 0 only if ToUnicode map maps the charcode to 0. CPDF_SimpleFont::UnicodeFromCharcode and CPDF_CID_Font:: UnicodeFromCharCode return 0 only if the call to CPDF_Font returns 0. In other cases, these methods return an empty string. So when processing text, a 0 return from the method should not be replaced with the charcode. BUG=pdfium:583 Review-Url: https://codereview.chromium.org/2342073002
2016-09-07Cleanup page when unloading in embedder testsdsinclair
When unloading a page in the embedder tests we need to cleanup the internal page map so if we load the page a second time we don't get a previously unloaded page. Review-Url: https://codereview.chromium.org/2322523002
2016-08-30Roll DEPS for build to b73bafdd.thestig
Also roll: buildtools to adb8bf4e. skia to 3ee255f2. v8 to 3d96d7ee. And make tweaks to get it all working. Review-Url: https://codereview.chromium.org/2283883002
2016-08-29Display content of the annotation when mouse hover.jaepark
Each annotation has its contents, and users should be able to see the contents. In this patch, PDFium creates a Popup annotation for each annotation and stores the author and the content. When a user mouse hover on the annotation, PDFium draws the corresponding Popup annotation and displays the content. Also, roll DEPS for testing/corpus to 5867fa6. BUG=62625 Review-Url: https://codereview.chromium.org/2273893002
2016-08-29Fix the test case added in https://codereview.chromium.org/2277063003/tonikitoo
In [1], it was made a mistake in the way the test case testing/resources/pixel/bug_492.pdf was generated. This CL aims at fixing this mistake by: 1- keep making use of the new pdfium_test capability introduced by [1], 2- add a proper .in file for the test case to generate its respective .pdf file. [1] https://codereview.chromium.org/2277063003/ BUG=pdfium:492 Review-Url: https://codereview.chromium.org/2286023002
2016-08-26Add support to Document::getAnnots methodtonikitoo
Although notably, the parameters handling support is not complete, CL intends to be the first step towards a more complete implementation of this API. TEST=testing/resources/javascript/bug_492_1.in BUG=pdfium:492 Review-Url: https://codereview.chromium.org/2281273002
2016-08-26Remove most things GYP.thestig
BUG=pdfium:559 Review-Url: https://codereview.chromium.org/2286653002
2016-08-26Extend pdfium_test capability so that more Javascript can be executedchromium/2841tonikitoo
In [1], the lack of support of pdfium_test to some application level hooks was felt. More specifically, the lack of implementation of the hook FFI_GetPage, called when 'this.getAnnot()' is executed in an Acrobar JS context, makes it non-trivial to JS texts that manipulate PDF annotations. [1] https://codereview.chromium.org/2265313002/ Here is the failing call stack in pdfium_test: 0 ::RenderPdf (samples/pdfium_test.cc) 1 ::FORM_DoDocumentOpenAction (fpdfsdk/fpdfformfill.cpp) 2 CPDFSDK_Document::ProcOpenAction (fpdfsdk/fsdk_mgr.cpp) 3 CPDFSDK_ActionHandler::DoAction_DocOpen (fpdfsdk/fsdk_actionhandler.cpp) <----v8----> 4 Document::getAnnot (fpdfsdk/javascript/Document.cpp) 5 CPDFSDK_Document::GetPageView (fpdfsdk/fsdk_mgr.cpp) 6 CPDFDoc_Environment::FFI_GetPage (fpdfsdk/include/fsdk_mgr.h) (frame 6 returns nullptr, and getAnnot call in frame 4 bails) CL extends pdfium_test app with a FFI_GetPage hook implementation. Basically what FFI_GetPage does is returning a FPDF_PAGE instance. In case of pdfium_test, FPDF_PAGE instances were only created on demand when the page was going to get rendered, and then discarded. Since FFI_GetPage can be called by JS before pages are rendered, CL moved the page creation code into a helper function, and cached the FPDF_PAGE instances created in a map, so it does not recreate them needlessly. BUG=pdfium:492 Review-Url: https://codereview.chromium.org/2277063003
2016-08-23Fix page leaks in an embedder testweili
Embedder test's delegate function GetPage() calls FPDF_LoadPage() to load a page which may be already loaded by embedder test itself. Thus the page's ref count is increased unnecessarily. This causes the page to be leaked. Fix this by putting the page map in embedder test class and guarantee the page is loaded only once. Also, fix leaks in this embedder tests by unloading the loaded pages to properly release the resource. BUG=pdfium:242 Review-Url: https://codereview.chromium.org/2258333002
2016-08-22Add fuzzer for CPDF_StreamParsertsepez
Review-Url: https://codereview.chromium.org/2262703003
2016-08-19Add a fuzzer for CPDF_HintTables.thestig
BUG=636559 Review-Url: https://codereview.chromium.org/2255083004
2016-08-19Stub out Document::syncAnnotScan method.chromium/2834tonikitoo
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
2016-08-18Add initial Document::getAnnot supportchromium/2833tonikitoo
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
2016-08-18Add llvm fuzzer for CPDF_PSEnginetsepez
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
2016-08-16Hidden annotations should not be drawntonikitoo
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
2016-08-15Push v8::Isolate into CFXJS_Engine classchromium/2831tsepez
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
2016-08-15Move some v8 objects from CJS back into FXJStsepez
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
2016-08-10Make Document's 'info' property readonlytonikitoo
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
2016-08-08Add support to Document::gotoNamedDest method.tonikitoo
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
2016-08-08Add support to Document::URL property getter.tonikitoo
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-18 23:26:51 +0000