Pages are out of order, missing, and duplicated in some multi-page PDFs |
||||||||
Issue descriptionVersion: canary 56.0.2896.0 (eb410d934c05) OS: macOS 10.12.0 16A323 Chrome does not display all of the pages in the PDF at http://www.phenom.aero/resources/library/garmin_radius_fix_legs_jan15_2013.pdf. The actual set of pages changes each time you load it. Right now, I have it showing (1, 29-30, 19, 31-38, 29-38, 29-38, …) in one tab. Note the duplicated pages and the out-of-order jumps. I loaded it in another tab and got (1, (blank?), 49-58, 49-58, …). Chrome always says it’s a 134-page document, but the pages are out-of-order, some are duplicated, and some are missing. I haven’t checked to see that Chrome actually shows all 134 pages, but see below for a smaller test case where things are missing. Bisected to https://chromium.googlesource.com/chromium/src/+log/5e7f9212eea94ed34e3a5755a2ed6d3f1eb3990e..680841c8ede6b061af2e46a161da7fa685320c51. There’s a PDFium roll in there at 991471745f77, which contains https://pdfium.googlesource.com/pdfium.git/+log/878dd5b121b3..7c29e27dae13. Of those two changes, 7c29e27dae13 (https://codereview.chromium.org/2414423002, bug 638513 ) is my suspect. This does not seem to affect every multi-page PDF. https://www.irs.gov/pub/irs-pdf/i1040gi.pdf is reasonable, for example. But https://www.nsaahome.org/textfile/journ/multipdf.pdf (which is the first Google result I get for “multipage pdf”) is a 3-page document that Chrome only shows two pages of (despite saying that there are three), and both of those pages are identical, the document’s first page. I’ve captured both of the test case files that Chrome isn’t displaying correctly here as attachments.
,
Oct 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dd41b79da9a6a4c8844b3b3e60735c31351022f9 commit dd41b79da9a6a4c8844b3b3e60735c31351022f9 Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org> Date: Thu Oct 20 20:14:04 2016 Roll src/third_party/pdfium/ 05259e98f..7403f8a2a (1 commit). https://pdfium.googlesource.com/pdfium.git/+log/05259e98f741..7403f8a2a0d8 $ git log 05259e98f..7403f8a2a --date=short --no-merges --format='%ad %ae %s' 2016-10-20 dsinclair Revert of Traverse PDF page tree only once in CPDF_Document (patchset #4 id:60001 of https://codereview.chromium.org/2414423002/ ) BUG= 657897 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, see: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls TBR=dsinclair@chromium.org Review-Url: https://chromiumcodereview.appspot.com/2441753002 Cr-Commit-Position: refs/heads/master@{#426578} [modify] https://crrev.com/dd41b79da9a6a4c8844b3b3e60735c31351022f9/DEPS
,
Oct 20 2016
mark@ would you be able to either test this on a ToT build, or tomorrows canary to verify the revert has solved your problem?
,
Oct 20 2016
Yes, that fixed it. Thanks for the quick revert, Dan.
,
Oct 21 2016
Verified the fix on Mac 10.11.6 using Chrome Dev #56.0.2897.0 as per the comment #0. Observed that all of the pages in the PDF at http://www.phenom.aero/resources/library/garmin_radius_fix_legs_jan15_2013.pdf rendered properly without any issues. Hence, the fix is working as expected. Attaching the screencast for reference Adding the verified labels.
,
Oct 21 2016
,
Oct 26 2016
,
Nov 28 2016
Issue 668929 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by dsinclair@chromium.org
, Oct 20 2016