summaryrefslogtreecommitdiff
path: root/testing/resources/javascript/bug_695826.in
AgeCommit message (Collapse)Author
2018-05-15Use {{streamlen}} macro in testing/resources/javascript/*.inTom Sepez
Change-Id: I1d2a91619a1c944b6fdca00b2f9c5bb338326986 Reviewed-on: https://pdfium-review.googlesource.com/32572 Commit-Queue: Tom Sepez <tsepez@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org>
2018-05-15Use {{trailer}} macro in testing/resources/javascript/*.inTom Sepez
Also format the trailer in a cleaner multi-line format. Change-Id: If145834b56f8678f97247b346cc0cfd4d367c501 Reviewed-on: https://pdfium-review.googlesource.com/32571 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Tom Sepez <tsepez@chromium.org>
2017-02-27Fix uninitialized memory read in CJS_Object::GetEmbedObject()Tom Sepez
The expected way to create native PDFium objects for JS is via the NewFxDynamicObject() call in C++, but that doesn't mean that the corresponding constructors won't be called from JS. In that case, the internal fields will be uninitialized, and subsequent method calls may try to use them. Add a constructor callback for all PDFium objects that nulls out these fields (shame that v8 doesn't do this by default, but probably saves some cycles). Then ensure that we check for this possibility in all the places it might turn up. Conversely, if we've just gotten a successful return from NewFxDynamicObject(), we know the CJS_Object/EmbedObj are good, so avoid checking there. BUG=695826 Change-Id: Iadad644c4af937def967ddc83daac1dad7544d69 Reviewed-on: https://pdfium-review.googlesource.com/2839 Reviewed-by: dsinclair <dsinclair@chromium.org> Commit-Queue: Tom Sepez <tsepez@chromium.org>