New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 809065 link

Starred by 12 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
new


Sign in to add a comment

Blank canvas elements when rendering PDF's in --headless

Reported by mrski...@gmail.com, Feb 5 2018

Issue description

Chrome Version       : 65.0.3312.0

URLs (if applicable) : https://dashboards.cluvio.com/dashboards/wx7y-53qr-pv5o/shared?sharingToken=759d96a5-da83-493c-833e-6b8f694a6189

What steps will reproduce the problem?
(1) Ensure you're operating with the --headless switch as this feature is only available in that mode
(2) Visit a website/URL with a <canvas> element that contains graphics.
(3) Use the PDF method of the remote protocol here: https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-printToPDF

What is the expected result?

Canvas elements should print out properly in PDF's

What happens instead?

Canvas elements are currently printed out as transparent/white.


Please provide any additional information below. Attach a screenshot if
possible.

Originally filed in the puppeteer project here: https://github.com/GoogleChrome/puppeteer/issues/1731 (I'll post a link back to this bug for visibility).

Also it appears that the screenshot method properly captures the canvas element's contents. I'm not sure if they use similar rendering means, but wanted to point that out as it could be an indicator.

Thanks!
 
Components: Internals>Printing
Status: Untriaged (was: Unconfirmed)

Comment 2 by i...@cluvio.com, Feb 5 2018

Couple more notes:
- printing to PDF in regular Chrome works correctly
- it is almost for sure not a timing-related issue, as a) waiting very long before rendering does not help and b) rendering screenshot first and pdf second (on the same browser instance via puppeteer) renders screenshot correctly and PDF blank
- may be related more specifically to WebGL (used by Mapbox-GL in the link above), as rendering other canvas content works without issue

Comment 3 by irisu@chromium.org, Feb 6 2018

Cc: jzfeng@chromium.org
Labels: -Pri-3 Pri-2
Status: Unconfirmed (was: Untriaged)
Labels: Needs-Triage-M65
We can replicate this issue - see https://github.com/ffffranklin/mapbox-headless-poc for example code of how WebGL canvases render to PDF as transparent images instead of map images.  This is also using the Mapbox GL JS library v0.45.0

Comment 6 Deleted

@Ryan I'm also seeing blank canvas elements when rendering PDF's of Mapbox GL JS maps, however when make puppeteer use google-chrome rather than chromium then it's working.

await puppeteer.launch({ executablePath: '/usr/bin/google-chrome' });

Comment 8 by thestig@chromium.org, Jan 17 (6 days ago)

Components: Internals>GPU>Canvas2D
Maybe folks that understand GL accelerated Canvas can help us understand why the print-to-PDF canvases are only blank in headless mode. Whereas normal printing works, and page.screenshot() in headless mode also works.

Comment 9 by thestig@chromium.org, Jan 17 (6 days ago)

Status: Untriaged (was: Unconfirmed)

Comment 10 by goanuj@google.com, Jan 17 (6 days ago)

Cc: goanuj@google.com

Comment 11 by ericrk@google.com, Jan 18 (4 days ago)

Components: Blink>WebGL
Owner: kbr@chromium.org
Status: Assigned (was: Untriaged)
kbr@, this sounds like it may be WebGL related - are there known limitations you're aware of re. headless WebGL or printing WebGL? Can you help triage?

Also, can anyone confirm the specific platforms this happens on. Right now I'm assuming any desktop platform?

Comment 12 by mrski...@gmail.com, Jan 18 (4 days ago)

I'm not sure if it's helpful, but this comment in Puppeteer's issue might be a signal to the issue: https://github.com/GoogleChrome/puppeteer/issues/1731#issuecomment-447629436.

I've also noticed that doing a <canvas>toDataURL() call doesn't work unless the drawing buffer is preserved (in _headful_). I'm not sure if that's intentional or not.

Comment 13 by kbr@chromium.org, Jan 18 (4 days ago)

Owner: ----
Status: Available (was: Assigned)
It's per specification that WebGL-rendered canvases drawn to other ones, read back, or having toDataURL done against them once they're composited returns a blank canvas with preserveDrawingBuffer:false.

Sign in to add a comment