Correction to the line 

$ display test.png | display -

Should have been:

$ cat test.png | display -

This was initially placed as a question on the Chrome product help forum:

- https://productforums.google.com/forum/#!topic/chrome/W_1Cf31TTjw

The issue seems to be out of TE-scope. Hence, adding label TE-NeedsTriageHelp for further investigation.

Thanks...!!

Adding a use case here.

Our application includes a calendar that agencies print and give to elderly clients who are more accustomed to physical paper than digital calendars. To generate this paper calendar, our customers click a Print icon.

Ideally, the server flow when the Print icon is clicked would look something like this:
  - Node generates the "print" HTML for the calendar
  - Node creates a child process for chrome --headless --print-to-pdf, piping HTML in on stdin
  - Node pipes chrome --headless stdout directly to the HTML response
  - Browser downloads a PDF

Without the ability to read from stdin and write to stdout, the flow is much more complicated:
  - Node generates the "print" HTML for the calendar, storing it in memory
  - Node creates a temp URL so a request from chrome --headless can access the generated HTML
  - Node creates a temp file for chrome --headless output
  - Node creates a child process for chrome --headless with a URL like http://localhost/temp123 and a temp filename
  - Chrome calls the temp URL, reads HTML, and writes to the temp file
  - Node pipes the file contents to the HTML response
  - Browser downloads a PDF
  - Node deletes the temp file and invalidates the temp URL

stdin and stdout would greatly simplify this process.

> chris.va...@gmail.com
> Adding a use case here.

I believe the DATA URI scheme already gives you the ability to load a page from Stdin.

$ cat test.html|chromium-browser "data:text/html;charset=utf-8,$(< /dev/stdin)"

Or, for it to be secure, convert it to base64 first:

$ cat test.html|base64|chromium-browser "data:text/html;charset=utf-8;base64,$(< /dev/stdin)"

Maybe even just URLEncode it instead of base64 would work, I'm not sure.

The base64 strategy is working great! That solves the stdin challenge.

I agree with the original poster though -- I would rather not need to enable FS write permissions on my web server to enable this use case, and a --stdout flag would fit my need perfectly.

> The base64 strategy is working great! That solves the stdin challenge.

It's kind of a hack.  I now see that Chromium imposes a limit on the size for data: (of 2MB ?):

- https://craignicol.wordpress.com/2016/07/19/excellent-export-and-the-chrome-url-limit/
- https://bugs.chromium.org/p/chromium/issues/detail?id=69227

Perhaps blob: instead of data: could be used which doesn't have the limit?

Or just have --headless accept the html on stdin if neither a file+path nor a URI was passed as an argument.   Or when in headless mode could explicitly specify to load from stdin with a  --stdin switch, or an -i switch even, or anything like that.

So yes, essentially this feature request is for support of both stdin and stdout.

stdin: for the contents of the resource to load
and
stdout: for the png or pdf output

Scratch my comment about the stdin challenge being solved. We easily ran into the limit on medium-sized datasets. For now, we will be using the temp URL strategy, in the hopes that we can replace it with a simpler stdin- and stdout-based strategy soon =)

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot