New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 74 users
Status: Available
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment
--kiosk-printing switch still shows a flash of the Print dialog for ~1 sec.
Reported by guido.du...@gfddgroup.com, Jan 9 2013 Back to list
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.
 
Labels: Feature-Printing
Can you try this again on Chrome Canary? There was a recent change made to this feature.
Labels: -Pri-2 -OS-Windows Pri-3 OS-All
Status: Available
Fixing this may be rather intrusive. In which case we probably don't want to do it, considering --kiosk-printing is not an officially supported feature.
Owner: thestig@chromium.org
@thestig, who's driving this feature? (or drove it, if it's no longer actively being developed)?


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. :)
Comment 5 by tjunus...@gmail.com, Jan 27 2013
this issue related to this 
http://code.google.com/p/chromium/issues/detail?id=31395
Project Member Comment 6 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-UI -Feature-Printing Cr-Internals-Printing Cr-UI
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.
Cc: vidster@chromium.org
+vidster, as this relates to kiosk printing use-cases.
Comment 9 by marm...@gmail.com, Aug 18 2013
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!
I agree with comment #9 it would be awesome to have some updates with this issue
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.
Hi - is there any way I can get a copy of the code that provides --kiosk-printing functionality please?
It would be great if author will fix this issue. Kiosk mode are very useful feature. 
Pls fix it!
Comment 16 by Deleted ...@, Feb 6 2014
 We need this feature, please fix it!!
Comment 17 by deed...@gmail.com, Feb 6 2014
Pls fix it! It is important
Damn, fix it! We use it a lot!
Very useful feature, please fix it
Plz, fix it
We need this feature, please fix it!!! 
Comment 22 by Deleted ...@, Feb 6 2014
please fix it!!!
Please fix it!
please fix it! very urgent
Please fix it
Comment 26 by Deleted ...@, Feb 27 2014
Please fix it
Comment 27 by Deleted ...@, Mar 2 2014
Please fix it!
Comment 28 by alis...@gmail.com, Mar 3 2014
It would be great, if this feature will be.
The feature --kiosk-printing doesn't work at all in the latest Chromium build on OS X Lion.

The --kiosk mode switch still seems to be working fine though.
I work for a major retailer and we have 2,500 Kiosks.  We would very much love for this to get fixed.  
Comment 31 by Deleted ...@, Nov 6 2014
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.
Comment 32 by Deleted ...@, Nov 13 2014
Fix it please! :...( It's very important for me too, I use it in queue mgmt system on 150+ kiosks, my boss and usual citezen are confused about appearing print preview.
Any news? 

Has anyone managed to do a workaround, except websocket connection to some java app?
Comment 34 by nrsan...@gmail.com, Dec 12 2014
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.
Comment 35 by marm...@gmail.com, Dec 12 2014
We gave up hope and settled on using http://qzindustries.com/ in the end. It works well and has given us very little trouble, there was just a fair amount of work up front getting it running.

I have (and still have) very little experience using Java in a web page and finding this https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/runAppletFunction.html made my life a lot easier.
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. 



Comment 37 Deleted
Issue 466441 has been merged into this issue.
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.
The raw string "printAutomaticallyInKioskMode" is still there in the print preview JS code. I think the feature still works, contrary to comment 37, but I need to double check.
kiosk printing works for me
Comment 42 Deleted
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.
Comment 44 Deleted
Comment 45 Deleted
Comment 46 by salut...@gmail.com, Mar 15 2016
Please remove the print preview flashing :)
Comment 47 by caki...@int.com.tr, Mar 17 2016
Yes, please remove print preview flashing, it looks very bad with kiosk apps
Please remove flashing print preview please,
This issue has been raised since 2013 and now 2016.
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?
Now that Google used the "copy and paste" Microsoft policy of "The bug stay, I don't care about you to solve it".

Anyone get a workaround? Maybe with another browser?
Comment 51 by a...@chromium.org, Dec 29 2016
 Issue 676009  has been merged into this issue.
Comment 52 by salut...@gmail.com, Dec 29 2016
Use nw.js
Comment 53 by yag...@gmail.com, May 29 2017
Please fix it! Very much expected!
Sign in to add a comment