Navigated to the URL "http://www.pdf995.com/samples/pdf.pdf" on Chrome Stable# 49.0.2623.87 and Chrome Canary# 51.0.2676.0 on Mac OS X 10.10.2 and could not reproduce the issue. 
Able to see the pdf without any abnormal behavior.
@adman.com -- Could you please let us know if there is anything else to do to reproduce the issue.
Thanks in Advance.

@msrchandra:
Verified issue still remains on Chrome stable# 49.0.2623.87 and Chrome Canary#  51.0.2673.0. on OSX 10.9.5. Testing on a different system with OS X 10.11.3 does not show the issue. Could also be related to the specific GPU (Intel Iris) in use on this device if not the operating system version.

I could not reproduce this error on a OS X 10.9 machine, with NVIDIA GeForce GT 750M 2048 MB graphics card.

Please clarify, why do you think this is a GPU-acceleration related issue? Does it go away when you turn off GPU acceleration?

Yep, passing --disable-gpu resolves the issue.

Thank you for providing more feedback. Assigning to requester "erikchen@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Users on Product Forums are reporting this issue after M49

 Issue 591956  has been merged into this issue.

Could you go to about:gpu, print the page to a PDF, and attach it? We'll probably have to find an exactly-matching machine to reproduce this.

Also, could you run from the command line with the flag --show-mac-overlay-borders, and attach a screenshot?

If this isn't in overlay mode (is green/red, not pink/grey) then I suspect this will be similar to the partial swap  issue 543324 . If that's the case, then I think we should just kill off partial swap on Mac -- CALayer overlays get us more power benefits, most of the time.

I'm affected by this issue on Chrome Version 49.0.2623.87 (64-bit). Attached is about:gpu

OSX 10.9.5 on late 2013 15-inch retina MacBook Pro

Here is a video with --show-mac-overlay-borders

https://youtu.be/oStEjaiCnTQ

Deleted: chromegpu.pdf 266 KB

chromegpu.pdf 266 KB Download

Okay, this is not the partial swap  issue 543324 .

We need to get a local repro. The test machine is
 Late 2013 15-inch retina MacBook Pro
 Intel Iris Pro GPU (VENDOR=0x8086, DEVICE=0x0d26)

I'm also seeing this issue:

Mid 2014 Retina 15-inch MBP
OSX 10.9.5
Chrome 50.0.2661.37 beta (64-bit)

Deleted: chrome___gpu.pdf 126 KB

chrome___gpu.pdf 126 KB Download

Unable to reproduce the issue on Mac 10.11.3 using chrome version 49.0.2623.87 and canary 51.0.2680.0.Able to view and scroll the PDF without any issues

Adding TE-NeedsTriageFromMTV as we don't have Mac 10.9.5 here.

Could any one from MTV team please look into this issue.

Thanks,

Seeing this across our district - but only on machines still on 10.9 (every 10.9 machine I've tested in fact). It's a variety of hardware but here is an example. Issue persists with Canary build and a clean install of OS.

13-inch, Mid 2012 Macbook Pro
Version 49.0.2623.87 (64-bit)

Deleted: chrome___gpu.pdf 138 KB

chrome___gpu.pdf 138 KB Download

Deleted: Screen Shot 2016-03-18 at 10.34.53 AM.png 128 KB

	Screen Shot 2016-03-18 at 10.34.53 AM.png 128 KB View Download

+M49 TPM and TE

I am able to reproduce the bug on MacBook Pro 2012 with OSX 10.9.5 with Chrome 49.0.2623.87.

I'm setting up a 10.9 machine to debug.

 Issue 592263  has been merged into this issue.

My test machine doesn't support running 10.9 (it's too new of a machine). I'll drop by MTV on Wednesday to get a new one.

That said, I'm pretty sure I know what the fix will be for this (disabling CoreAnimation renderer on 10.9 -- it'll hurt battery some, but not upgrading your OS is also bad for battery, contrary to popular belief).

Removing from bisect queue, seems Chris is aware of the root cause.

 ccameron: Was CoreAnimation not enabled in pre Chrome 48 and earlier wrt to PDFs?

Patch is at https://codereview.chromium.org/1819193002/.

It was not enabled in Chrome 48.

 Issue 596550  has been merged into this issue.

I can't reproduce this on my 10.9 machine, which I guess I already knew, since I tried in Comment 4.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/52dd784270ee9386ceba4e29c198c86dea9912dc

commit 52dd784270ee9386ceba4e29c198c86dea9912dc
Author: ccameron <ccameron@chromium.org>
Date: Tue Mar 22 03:29:03 2016

Disable CALayer overlays on 10.9

This is causing issues with PDF and print-preview for yet-unknown
reasons. Hopefully we can re-enable CALayer overlays when we find the
fix.

BUG= 594343 

Review URL: https://codereview.chromium.org/1819193002

Cr-Commit-Position: refs/heads/master@{#382498}

[modify] https://crrev.com/52dd784270ee9386ceba4e29c198c86dea9912dc/content/browser/compositor/browser_compositor_overlay_candidate_validator_mac.mm

I'm experiencing this issue as well. 

MBP Retina, 15-inch, Mid 2014
OSX 10.9.5
Version 49.0.2623.87 (64-bit)

The CL in Comment #32 does not fix the problem.

Also try --disable-remote-core-animation to see if that makes the issue go away.

Issue persists.

Next idea: make IsGpuMemoryBufferCompositorResourcesEnabled() return false.

After that I'm out of ideas.

Are we only seeing this on some GPUs on 10.9? Are any of these GPUs blacklisted?

You are probably looking for a change made after 376015 (known good), but no later than 376065 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/4967b70a63b618a6e508db88c2fa9c5dbef206f4..7723a589545f0d5b59ad792f6285fe9cb5a46c7a

Given that the base revision for M49 is good, the culprit CL was probably merged to M49.

Most suspicious:
c789639 Clear IOSurfaces immediately after creating them. by erikchen · 5 weeks ago

Testing now.

I've confirmed that that CL is responsible, though I have no idea why. I asked weili@, and she said that on Mac, pdfium uses a custom backend which uses native apis to do drawing. They want to switch to Skia, but that hasn't happened yet.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/pdfium/core/fxge/apple/

Nothing immediately jumps out as a problem point. I checked the return values on IOSurfaceLock/Unlock, and those are always 0. My best guess is that when we clear the IOSurface, somehow, we also end up clearing some, or all of the context that pdfium is trying to draw into.

This is a change we made 5 weeks back. What is the impact of that change? Is it reasonable to revert it (seems like it would be a clean revert?) till we can figure out what the problem is?

All the users who have posted problems have Intel GPUs.

When I turn off Automatic Graphics Switching (forcing NVIDIA GPU), problem also goes away.

I tried CPU clearing the IOSurface to (0, 255, 0, 255) within the IOSurfaceLock/Unlock combination, but that had no effect on the nature of the PDF rendering problems.

This CL: https://codereview.chromium.org/1826613002/
turns off IOSurface clearing on OS X 10.9

rsesek: Can you comment on whether this security tradeoff is acceptable?

Given that this is a significant regression and we're only going to affect 10.9, I think it's an acceptable tradeoff. But it seems like this is a bug in PDFium that should be filed and chased down separately, so that we can revert that CL later.

Any idea when the switch to Skia is coming, so we have a worst-case scenario of how long we might need this workaround? 

When I correctly clear the newly minted IOSurface to green [CPU clear], it also clears much of the rendered PDF. 

Deleted: Screen Shot 2016-03-22 at 3.15.53 PM.png 1.8 MB

	Screen Shot 2016-03-22 at 3.15.53 PM.png 1.8 MB View Download

 Issue 597008  has been merged into this issue.

+tsepez

Can you respond to Comment 48?

+thestig +reed

+cary to address comment 48: "How long til skia?"

+patricia

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f38d1ce51f77c495dffb59d9c8d557881f3df448

commit f38d1ce51f77c495dffb59d9c8d557881f3df448
Author: erikchen <erikchen@chromium.org>
Date: Wed Mar 23 00:07:58 2016

Disable IOSurface clearing on OS X 10.9.

Doing so triggers PDF rendering problems on some GPUs.

BUG= 594343 
TBR=avi@chromium.org

Review URL: https://codereview.chromium.org/1826613002

Cr-Commit-Position: refs/heads/master@{#382739}

[modify] https://crrev.com/f38d1ce51f77c495dffb59d9c8d557881f3df448/ui/gfx/mac/io_surface.cc
[modify] https://crrev.com/f38d1ce51f77c495dffb59d9c8d557881f3df448/ui/gl/test/gl_image_test_template.h

Per chat with sshruthi@, approving merge to M49 (branch 2623). The plan is to have merge in, cut a build of M49, and then verify on tomorrow's canary. If something goes wrong, we can cut another Stable build later on.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0ecd929bf77adc013f3caaf244b36fe630c5a80

commit a0ecd929bf77adc013f3caaf244b36fe630c5a80
Author: erikchen <erikchen@chromium.org>
Date: Wed Mar 23 00:25:43 2016

[Merge to 2623] Disable IOSurface clearing on OS X 10.9.

Doing so triggers PDF rendering problems on some GPUs.

BUG= 594343 
TBR=avi@chromium.org

Review URL: https://codereview.chromium.org/1826613002

Cr-Commit-Position: refs/heads/master@{#382739}
(cherry picked from commit f38d1ce51f77c495dffb59d9c8d557881f3df448)

Review URL: https://codereview.chromium.org/1825283003 .

Cr-Commit-Position: refs/branch-heads/2623@{#650}
Cr-Branched-From: 92d77538a86529ca35f9220bd3cd512cbea1f086-refs/heads/master@{#369907}

[modify] https://crrev.com/a0ecd929bf77adc013f3caaf244b36fe630c5a80/ui/gfx/mac/io_surface.cc
[modify] https://crrev.com/a0ecd929bf77adc013f3caaf244b36fe630c5a80/ui/gl/test/gl_image_test_template.h

Re #48: PDFium's Mac graphics backend is a mixture of calls to CoreGraphics and agg aka Antigrain. Additionally, PDFium draws some primitives by allocating a bitmap and setting the pixel values directly.

Replacing all this with Skia is an ongoing investigation. Some PDFium features may require further development of Skia to fully implement. No ETA.

Verified the issue is fixed on Mac OSX 10.9.5(Machine I where I was able to repro) with Chrome Canary i.e., 51.0.2688.0.

Note : Also cross checked on Mac OSX 10.10.5 and 10.11.3 machines and not marking the bug as fixed since the CL need's to be verified on M50 and M49 as well.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/87c0cfd98a88e8bde7f83ad18de32a87664d388b

commit 87c0cfd98a88e8bde7f83ad18de32a87664d388b
Author: erikchen <erikchen@chromium.org>
Date: Wed Mar 23 17:54:04 2016

Disable IOSurface clearing on OS X 10.9.

Doing so triggers PDF rendering problems on some GPUs.

BUG= 594343 
TBR=avi@chromium.org

Review URL: https://codereview.chromium.org/1826613002

Cr-Commit-Position: refs/heads/master@{#382739}
(cherry picked from commit f38d1ce51f77c495dffb59d9c8d557881f3df448)

Review URL: https://codereview.chromium.org/1829843002 .

Cr-Commit-Position: refs/branch-heads/2661@{#361}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/87c0cfd98a88e8bde7f83ad18de32a87664d388b/ui/gfx/mac/io_surface.cc
[modify] https://crrev.com/87c0cfd98a88e8bde7f83ad18de32a87664d388b/ui/gl/test/gl_image_test_template.h

hey erikchen@, pls wait for merge approval in the future before you merge into a release branch. Thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09b6b31bbf4dc3de1ac5f8e31de9fabdd2e9f427

commit 09b6b31bbf4dc3de1ac5f8e31de9fabdd2e9f427
Author: ccameron <ccameron@chromium.org>
Date: Wed Mar 23 22:20:08 2016

Revert of Disable CALayer overlays on 10.9 (patchset #2 id:20001 of https://codereview.chromium.org/1819193002/ )

Reason for revert:
Wasn't helpful.

Original issue's description:
> Disable CALayer overlays on 10.9
>
> This is causing issues with PDF and print-preview for yet-unknown
> reasons. Hopefully we can re-enable CALayer overlays when we find the
> fix.
>
> BUG= 594343 
>
> Committed: https://crrev.com/52dd784270ee9386ceba4e29c198c86dea9912dc
> Cr-Commit-Position: refs/heads/master@{#382498}

TBR=erikchen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 594343 

Review URL: https://codereview.chromium.org/1830733003

Cr-Commit-Position: refs/heads/master@{#382943}

[modify] https://crrev.com/09b6b31bbf4dc3de1ac5f8e31de9fabdd2e9f427/content/browser/compositor/browser_compositor_overlay_candidate_validator_mac.mm

Verified that the issue is fixed on Mac OSX 10.9.5(Machine I where I was able to repro) with Chrome M49.

Note : Also cross checked on Mac OSX 10.10.5 and 10.11.3 machines and not marking the bug as fixed since the CL need to be verified on M50.

This patch is now pushing out to stable channel in version 49.0.2623.108.

Verified fixed on stable 49.0.2623.108. Thanks guys!

49.0.2623.108 resolves the issue for me too - thanks!

Verified that the issue is now fixed on all Chrome Channels i.e.,Stable(49.0.2623.108 and .110), Beta(50.0.2661.57), Dev(51.0.2693.2) and Canary(51.0.2694.1)on Mac OSX 10.9.5,Marking the bug as verified.

I'm using Google Chrome 49.0.2623.110 m and this problem is still happening to me (white page from internet and from PC with PDF files. Interesting is that this happens occasionally). I use Microsoft Windows 10 64-bit. I have tried to allow/disable GPU acceleration, but problem continues. 

vapse...:
Since you're not on OS X the issue you are seeing is different to this one (even if the symptoms may be similar). I'd recommend that you search for a bug that matches your problem but on Windows or that you file a new bug report if you can't find anything.

sits...: 
I already made bug report about my problem but someone thought that it is best to merge my issue https://bugs.chromium.org/p/chromium/issues/detail?id=591956 with this (https://bugs.chromium.org/p/chromium/issues/detail?id=594343) bug. I don't think that OS X and Windows problem is duplicate, but he/she (https://bugs.chromium.org/u/1084958462/) thought that it is.

Has this issue reappeared? I'm on Chrome 57.0.2987.133 (64-bit) on macOS Sierra and am seeing the same issue (completely grey page for pdfs) unless I turn off hardware acceleration.

jni.s...@gmail.com:
I'm on Chrome 57.0.2987.133 macOS 10.12.4 using a machine that saw the original issue. I don't see this problem on PDFs that originally made it happen so I would strongly suggest that you open a new issue for the problem you're seeing and post reproduction steps inside (could be linked to exact PDFs, hardware etc).

I've experienced similar symptoms on my Mid 2015 15-ince MacBook Pro for at least a year (since April 2016). The PDF viewer seems to stop working on all tabs simultaneously. The problem does not seem to be triggered by any PDF in particular, just by leaving PDF viewer tabs open for a long time (days to weeks). It happens pretty consistently and I have to restart Chrome to fix it.

I would recommend filing a new bug report and reference this one. Though the symptoms are similar, the cause may be different this time.