Issue 169004:
--kiosk-printing switch still shows a flash of the Print dialog for ~1 sec.

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.45 Safari/537.17
Steps to reproduce the problem:
1. Run with --kiosk --kiosk-printing
2. Try to print (window.print() or Ctrl+P, I guess)
3. Notice the printing dialog flash for a split second even if the user cannot use it.
What is the expected behavior?
Chrome should print silently. The dialog should not be shown at all, it should be hidden, off-screen or run in the background.
What went wrong?
Silent printing is still not silent.
Did this work before? No
Chrome version: 24.0.1312.45 Channel: n/a
OS Version: Any
This is important for kiosks that print receipts via thermal printers, etc.
Users get confused when seeing that screen flash. The time the screen appears depends on the computer's performance.

The only thing driving this is demand from users for some kind of kiosk mode where one can print to a pre-selected printer with the pre-selected settings without prompting. Though recently I discovered we have a real feature with the feature=kiosk label. You may want to check with the PM for that feature and see if this is something they are interested in.
--kiosk-printing as currently implemented is a quick and dirty feature I added to help out the users. I never said it was going to be pretty. :)

This feature will be pretty important to kiosk using a thermal printer, I'm currently looking to Firefox because it has that feature and can be enable in about:config. Please can you tell us how we can help or where in the code we should start to look.

Is it possible to have an update on the likelihood of this being addressed? The flash of the print preview is really ugly and at the moment we have to use https://code.google.com/p/jzebra/ to get true silent printing but it's awful, buggy and it would be nice to not have a dependency on Java.
If this is not going to be addressed it would be handy to know so that we know to investigate other options.
Thank you!

As far as I can tell, this code in Chrome is unowned. thestig added --kiosk-printing on request and sounds unlikely to work further on it given comment 4.
If it's truly unowned, we probably should remove the code from Chromium entirely. I would be happy to see an alternative where someone steps up to own this feature. This would be an appropriate thing for a member of the public community to do. Such an owner could hopefully either implement or at least review a patch to fix this bug.
That is all a long-winded way of saying: I see no opposition to fixing this, but it's never going to happen unless someone steps up to do it. Chromium is open-source; if this is worth doing, hopefully there's someone out there willing to do it.

It's not much of a maintenance burden, and it's very little code, so I'd prefer to not remove it since it is useful to many users who are making browser-based kiosks.
And indeed, it's open source and anyone is welcome to help out, which is why the bug status is set as available. Patches welcome.

My company has a process that uses the --kiosk --kiosk-printing feature. The HTML contains the line <body onload="window.print()">.
This works fine automatically printing the document from a commandline, but we have a process that calls this from a service. This used to work (about 6 months ago) running from a service, but now it fails to print (with version 38.0.2125.111 m). Did you make a change in the last few months that disables this from working when being launched from a service? Is there something on the command-line that will allow the service to work again?
We use this in a business process that prints to a file that then gets converted to another format such as PDF and then gets routed to another location.

atomase...@gmail.com, You can try to have a local app that runs a local server, for example, http://localhost:8080 and your web app make a ajax request with the content to print and your local app does the print job.
You can do that with PHP for example.
Web App > Local App (installed by the user) > Printer.
Isn't a perfect solution but its a solution.

nrsan...@gmail.com, marm...@gmail.com: thanks for a fast responses, I've been banging my head against the wall for the last three days.
It's such a shame this wasn't fixed, but I'll look into both your solutions. I'll have 4 remote kiosks across country (on avg. 200 miles distance between me and the kiosk) and I'm looking for something that won't be causing me much trouble.

thestig: It doesn't look like the flag here is ultimately plumbed to anything anymore. kPrintAutomaticallyInKioskMode gets set but nothing reads it AFAICT.
Given this, we really should either re-plumb the flag (not sure what happened) or completely remove this.

Re: comment 42 - Historically, Chromium did not include the PDF plugin because it was proprietary, and print preview was turned off. Thus no print preview means --kiosk-printing would not work. We open sourced the PDF plugin last year as PDFium, so that restriction no longer applies, and Chromium should have print preview now. However, we do not release Chromium builds for RPis, so take that up with whoever built your copy of Chromium. This is getting a bit off topic, so please consider continuing that discussion somewhere other than this bug report.

In addition to the --kiosk-printing producing the brief flash, it also has the side effect on printing blank pages depending on the length and complexity of the rendering of what's being printed. We've observed a common result of being able to completely print 1-3 pages, but often seeing pages 4 and 5 being blank.
The equivalent behavior can be reproduced by not using the --kiosk-printing flag and very quickly pressing the "print" button in the print preview dialog.
This reported issue (the flash) is mostly cosmetic, but the blank pages portion cannot be worked around by the user if chromium is being used in a kiosk like manner (e.g. no OS access or visibility of the print preview dialog since it too allows access to the OS).
Since per comment 4: "--kiosk-printing as currently implemented is a quick and dirty feature I added to help out the users." and from other references its been said to not be supported, could the author thestig@chromium.org at least provide a suggested approach to fixing the printing of blank pages problematic behavior?
In theory, it doesn't sound difficult to fix, if the rendering thread would only signal/message to the browser thread that its OK to close after rendering has totally completed, then no blank pages would result. However, if that rendering took too long, that would result in the print preview dialog being visible for a longer time.
Are there any suggestions on how to perform the same work without creating a visible print preview dialog?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot