I know it has been discussed here before, yet I found no practical solution/workaround for this, I'm hoping if someone has any idea how to resolve this problem!

Here's it is:

If you try to call window.print() method frequently within a single page(as if a user clicks on a print button) in google Chrome, the browser throws a warning message in the console, stating:

Ignoring too frequent calls to print()

And nothing happens! After several seconds, things go back to normal and print dialog appears the moment you call window.print() command again! To make matters worse, the good Chrome folks use exponential wait time for a page that calls print command, meaning the more user clicks on a button to print, the more he has to wait for the print dialog to appear!

This issue has been in chrome for quite some time (14 subsequent versions) and it is confirmed as being an Area-UI bug, I posted it again for google team yesterday hoping if someone from Chrome team can verify when this incredible annoying feature is going to be fixed!

However, what I'm looking for here is a workaround for this problem, is there anything I can do be able to get this working? My company is developing a highly transactional financial system with lots of reports that needs printing, and for just this one little glitch, the whole project is at risk of running in my favorite google Chrome browser!

Update:

Here's the code in Chrome browser that causes this feature and it looks like that at least 2 seconds is needed before someone calls print command again, so a timer of 2 seconds interval in UI could possibly prevent getting into an infinite wait callback! any other thoughts?

I know it has been discussed here before, yet I found no practical solution/workaround for this, I'm hoping if someone has any idea how to resolve this problem!

Here's it is:

If you try to call window.print() method frequently within a single page(as if a user clicks on a print button) in google Chrome, the browser throws a warning message in the console, stating:

Ignoring too frequent calls to print()

And nothing happens! After several seconds, things go back to normal and print dialog appears the moment you call window.print() command again! To make matters worse, the good Chrome folks use exponential wait time for a page that calls print command, meaning the more user clicks on a button to print, the more he has to wait for the print dialog to appear!

This issue has been in chrome for quite some time (14 subsequent versions) and it is confirmed as being an Area-UI bug, I posted it again for google team yesterday hoping if someone from Chrome team can verify when this incredible annoying feature is going to be fixed!

However, what I'm looking for here is a workaround for this problem, is there anything I can do be able to get this working? My company is developing a highly transactional financial system with lots of reports that needs printing, and for just this one little glitch, the whole project is at risk of running in my favorite google Chrome browser!

Update:

Here's the code in Chrome browser that causes this feature and it looks like that at least 2 seconds is needed before someone calls print command again, so a timer of 2 seconds interval in UI could possibly prevent getting into an infinite wait callback! any other thoughts?

• javascript
• google-chrome
• printing

Share Improve this question Follow edited May 13, 2012 at 16:18 Kamyar Nazeri asked May 1, 2012 at 17:14 Kamyar NazeriKamyar Nazeri 26.5k1515 gold badges5454 silver badges8888 bronze badges 5

• 2 The only work around I could think of is to have an internal timer (to track when its ok to call print) and when the print button is pressed have an animation similar to an AJAX one until print is really called. This is not great as it still delay the print procedure but it would look better than and error popping out. – GillesC Commented May 1, 2012 at 17:22
• 2 @gillesc: Yes, that's better than having "nothing" when clicking on a button and you click again and again making it worse! I found the line of code in Chrome browser that causes this feature:git.chromium.org/gitweb/… and it looks like that at least 2 seconds is needed before someone calls print command again, so a timer of 2 seconds interval could possibly prevent getting into an infinite wait callback! – Kamyar Nazeri Commented May 1, 2012 at 17:30
• 1 Are the calls to window.print on the same page or different pages? If different, are they in a new window/tab or iframe? Or the same tab, via a redirect? – apsillers Commented May 4, 2012 at 18:23
• 1 window.print command is on an iframe within the page, I'm building a report viewer component with all the means necessary for handing the report like: next, previous, find, export and print buttons. the latter causes the problem in google Chrome – Kamyar Nazeri Commented May 4, 2012 at 19:21
• Hopefully the issue gets resolved, but underscore's debounce sounds like a viable workaround. documentcloud.github.com/underscore/#debounce – gerges Commented May 9, 2012 at 18:17

Add a comment  | 

7 Answers 7

Sorted by: Reset to default 19 +50

You could conditionally replace the window.print() function:

// detect if browser is Chrome
if(navigator.userAgent.toLowerCase().indexOf("chrome") >  -1) {
    // wrap private vars in a closure
    (function() {
        var realPrintFunc = window.print;
        var interval = 2500; // 2.5 secs
        var nextAvailableTime = +new Date(); // when we can safely print again

        // overwrite window.print function
        window.print = function() {
            var now = +new Date();
            // if the next available time is in the past, print now
            if(now > nextAvailableTime) {
                realPrintFunc();
                nextAvailableTime = now + interval;
            } else {
                // print when next available
                setTimeout(realPrintFunc, nextAvailableTime - now);
                nextAvailableTime += interval;
            }
        }
    })();
}

Instead of using an external safety timer/wrapper, you can use an internal one. Just add this and window.print behaves safely in Chrome and normally everywhere else. (Plus, the closure means realPrintFunc, interval and nextAvailableTime are private to the new window.print

If you need to coordinate calls to window.print between multiple framed pages, you could set nextAvailableTime in the parent page, rather than in the closure, so that all the frames could access a shared value using window.parent.nextAvailableTime.

I've been bumping up against the same issue, and the most direct solution for me was to just create a new window, write what I need to it, close it, and print it. I haven't had to deal with Chrome's limit since I changed it to work this way, and I don't need to do any tracking.

print_window= window.open();
print_window.document.write(print_css + divToPrint[0].outerHTML+"</html>");
print_window.document.close();
print_window.focus();
print_window.print();
print_window.close();

My solution would be to call the window.print() less frequently. You could try wrapping window.print() into a method of your own and put a minimum time interval that has to pass before the window.print() is executed again. You can have some kind of change/animation in UI to indicate that work is being done.

"Working"

Unless you think it really think pressing print-button more than once a second/every few seconds helps? I mean if the window.print() operation takes that long it's not your codes fault and there should be a "wait and be patient" -indicator in UI anyway.

If all your printers are network-compatible, you could change what happens when clicking on the print button. Instead of printing the page, your application could send a request to a server with the URL of the page to print and with an information on which printer to print.

The server then launches the print process manually and there will be no browser in between, which could stop you from doing so.

Everywhere I see mentioning this issue suggests using timers. However they do not solve the issue and I feel like Kamyar is the only person who actually read the source and understands the problem, so I do wonder why he accepted the answer he did.

The main problem is that the length of the delay in Chrome is exponential, so for these timers to work their delay has to also be increased on every usage which of course would get very annoying very quickly. Chrome actually only applies the delay after cancelled print requests but we can't detect whether a print is successful or not anyway.

Abathur's solution actually works much better than you might expect. I'm not sure if I'll use it but it does work.

The good news:

1) The delay is actually reduced in more recent versions of Chrome. It now goes: [2, 2, 2, 4, 8, 16, 32, 32, ...].

2) Someone took up the issue on August 28th: http://code.google.com/p/chromium/issues/detail?id=50186 If you want this issue resolved then please go star it.

No more work-arounds! Bug fixed as part of v.23 if I'm not wrong.

So if the release cycle is every 6 weeks and Chrome 22 was released 25th of Sep, then by 6th of November (aprox.) the fix will be in the Chrome Stable version

I'm doing something similar to escape a sandbox..and it works perfectly on firefox but not on edge/chrome. I've tried a number of other things. Do you recall anything helpful on the topic?

print_window= window.open();
print_window.document.write( <...> );
print_window.document.close();
print_window.focus();
print_window.print();
print_window.close();