What is it doing during those 1-2 minutes? Does the print preview dialog hang around? Is printing faster without --kiosk-printing?

the dialog box appears and after a few seconds it disappears (this is normal), the problem is that after it disappears it takes between 1-2 minutes to get the print to my printer, when normal should be The dialog box disappears automatically my printer should receive the impression

What model is the printer? Is it directly attached via USB or a cloud/network printer?

Did you try without --kiosk-printing? Is that faster or just as slow?

the problem is not the printer i try with 2 but also i try with PDF Architect( it convert the printer in PDF), i note the message to print take many time to get, and when it happend, so the printer go to print, i try without --kiosk-printing too and when i press click in the button of the print dialog, the process dont have problem and all is good

If you are using the same "printer" with the same settings, then I can't think of any differences between the kiosk vs non-kiosk mode. Basically the only thing --kiosk-printing does is push the print button automatically.

Windows 10 has a couple of built-in virtual printers: "Microsoft Print to PDF" and "Microsoft XPS Document Writer". Does the slowness occur with either of those? If so, I can try it and see how it behaves for me.

same... Another thing I just noticed, is that after the dialogue closes and during the time it takes to lay the print the web page hangs

Tried the issue on Win 10 using latest stable # 57.0.2987.133 and got the print(RICOH laser printer) without any delay.
Even no delay in save as PDF.
Please help providing the printer made and model to investigate further.

please Close all Chrome intances, go to the Chrome.exe(launcher on the desktop) and right click and property, in destination put  "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --kiosk --kiosk-printing https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_print

now try to print

the problem happend when you try to use the --kisok-printing mode

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

The cause of the problem is version 57.
I checked versuon 49 and 56 - no problem. The only solution install older version from http://www.geocities.jp/ecvcn/exam/chrome_installer.html

 Issue 706409  has been merged into this issue.

Using printers: EPSON TM-T20II, Canon MP280 on Windows 10, I can confirm that the javascript event onafterprint is fired only after 1-2 minutes of waiting if you print in --kiosk-printing mode. 

Also, some functions (but not all) on the page seemed to stop working, sort of freezed-like (maybe a thread is stuck?), and fired only after the onafterprint event. Without the --kiosk-printing, the onafterprint event is fired normally. 

And I've already noticed the slow printing on v56, but those took like 10 seconds each only. This time on v57 they take 1-2 minutes each. 

If I change the print destination to "Save as PDF" then it works fast without delay.

I hope this helps.

I have the same issue on windows 10 running chrome 57. --kiosk-printing is leaving 11 systems I have in different areas of the state all with 1-2+ minute lag times between printing but without kiosk printing it is immediate.

the question is who will fix it, and where....

Experiencing the same issue for our application. The next question is when will this get fixed and pushed to clients?

According http://stackoverflow.com/a/43180906/3032403 chrome canary have not bug, I do not checked.

Experiencing this issue with Chrome 57.0.2987.133 on Windows 7 and 10 (we have both in production) 64bit, printing on Brother QL-700 printers with kiosk printing. All print jobs take about 30-60 seconds to hit the spooler, and then the docs are printed.

When we turn off kiosk printing and just use Chrome in fullscreen mode, there is no issue. We're about the make that changeover until this issue is resolved.

I do not know what the procedure is, but what I see is that many days have already passed, and this error continues to appear as "unconfirmed"; Then I wonder this will not have a solution? Or is it little important for developers ??

Rumor is, is that its corrected in Chrome Canary, so fix is probably in beta and not officially released yet... hopefully. And there is not a reason to changeover, just downgrade to v56 here http://www.geocities.jp/ecvcn/exam/chrome_installer.html

 Issue 708448  has been merged into this issue.

Tested --kiosk-printing in Chrome Beta (58) and seeing normal behaviour. 

Expected stable release date for Chrome 58 is April 25th. https://www.chromium.org/developers/calendar

RE: comment 22 - now that Chrome 58 has been released as Stable is this still an issue? Any problems in Canary or other channels?

I have no idea, I already stopped using Google Chrome in my business, it seems to me a lack of professionalism that in the face of such a serious error, the status of this post continues to appear as "Unconfirmed", I preferred to develop my own browser :)

Thank you for providing more feedback. Adding requester "rbpotter@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

We have tested Chrome 58 and we do not have any issue with kiosk printing anymore.

Same here, Chrome 58 fixed the issue for us.

We're very likely to lock in the Chrome version used in production after this point to prevent issues like this from happening in the future.

Also moving towards a PDF download-and-auto-print setup, which would remove our dependence on kiosk printing.

We have been running locked Chrome versions since v54 but there are cases that computers got updated without warning.

Maybe you could have in mind to change the browser, this problem almost ends with my business, check about cefsharp and do it yourself

Thank you for providing more feedback. Adding requester "rbpotter@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thank you for confirming this is fixed. Closing the issue for now, but happy to re-open if this is still an issue for anyone in Chrome 58 (or you can open a new issue).

Also, with regard to different Chrome versions, you can test using Chrome Canary and other channels (Dev/Beta) to see what is coming in future versions ahead of time, and report any bugs you may find. Bugs caught on Canary and other channels can often be fixed before they reach Stable.

Chrome 58 doesn't fix this reliably. Using 3 identical machines (group policy) in a kiosk setup, use being for producing user passes for visitors and contractors coming onto our company's site. We are still getting fairly regular hanging on the print action on one or two of the machines, whilst one is always working fine. We definitely had all three working simultaneously with no issues on 56.

same, not reliably fixed, I have few kiosks setup with chrome 58 but the issue is only resolved on a couple of them and the rest are still facing the issue. 

Okay, re-opening. Will try to reproduce this soon.

For those that are seeing this inconsistently: is it consistent per machine? I.e. if a machine works correctly, it always works correctly, and if a machine has slow kiosk printing it is always slow? Or is it an issue that occurs inconsistently on any given machine? If it is inconsistent, about what percentage of print jobs are affected by slow printing?

Sorry for dropping off on this bug, but now we managed to reproduce the problem and we can better explain what is going wrong.

It looks like renderer processes are being too aggressively or incorrectly suspended. This bug showed up with r437036. At one point the problem went away when r460519 reverted r459787.

It looks like we are aware of some of these issues. e.g.  bug 702160  mentions calling print() in JS. So assigning this to altimin@ to make sure we get this use case completely fixed.

For those running businesses that are affected, my advise has always been to periodically test Canary, Dev, or Beta channel so problems are detected early before they reach production with Stable channel. We do try to test, but we cannot test the combination of every use case multiplied by every hardware+software configuration. It's benefits everyone if you test your own configurations with upcoming Chrome releases. Tat way Chromium developers have more time to investigate and fix problems. Your businesses will only have a single broken test machine, instead of a fleet of broken machines.

Ridiculous, every businnes machine is a testing machine because chrome has no "disable autoupdate" button.

I'd like to suggest to try using --disable-background-timer-throttling flag? My theory here is that --kiosk does something strange with page visibility, so we consider it backgrounded and throttle. If this is right, maybe automatically implying --disable-background-timer-throttling flag when --kiosk flag is present is the right thing to do.

P. S. Do we have any test coverage for --kiosk flag?

I understand that the chrome development team has many bugs, I have my development company and I have to deal with problems many times and delegate functions and all those things, but this error is important, many shops use the kiosk to make their sales , And the best option for a small business is to use the chrome. But when something like this happens it leaves a bad taste in my mouth, 2 months after I reported the error, after many people confirmed the bug, after the release of a new version and after having supposedly solved the error (this is the Part more worrisome, to say that something is solved and not really) the error still continues, after so much time, they just tell us that they could reproduce the error !!!!!
I sincerely think that they should try to create new, more effective channels for reporting errors, because honestly this is not working well, and I say it in all honesty, someone who, like so many, entrusts your business to you, and that trust almost makes my business fail ; Do not lose more users and look for a better solution, for my part I decided to do this for myself and now I work with my own browser but there are many who do not have the right knowledge to do this and trust you, so please try to Improve things.

PS: The idea of ​​being able to disable the updates I think should be taken into account, I'm sure that's not the only problem they will have, and I think they could let the final client choose which version to use, at least until their problem can Be solved.