I am also facing print issue in chrome 77 version. Using below code for print function 

pdfStamper.addJavaScript("this.print({bUI: true,bSilent:false,bShrinkToFit: true});");

Any body help to resolve the issue.

@XicoFininho your solution is okay as long as telerik implementation is done using the telerik reports WebApi inside MVC project (same domain).

Today with the 'Micro services' architectures most engineers choose to create another website only for the Telerik Reports WebApi.

This is how we have done it and your solutions does not work this way because of CORS issue with iframe printing something from a different domain.

And that's why the PrintJsis being used as a solution in the KB article.

Thanks

Hi, 

I don't think you specifically need to use PrintJS to print the report as that will just internally be calling window.print() anyway, all you need is to tell the iframe window to print. The issue in Chrome is that the iframe itself can't have JS to tell itself to print but the calling window opening the iframe still can still issue a print command. 

As per my last comment, when using the HTML5 report viewer you can either modify the JS source to add the 2 lines in (which was previously suggested by Nasko) or add the following JS in to modify the print function to call .print() on the opened iframe window which will work in any browser as long as it has a PDF plugin installed. Any browser without a PDF plugin will just ask to save the document first, there's no way around that of course. 

<script type="text/javascript">

$(function () {

var frame;
window.telerikReportViewer.printManager.print = function printPdf(src) {

if (!frame) {
frame = document.createElement("IFRAME");
frame.style.display = "none";
}

frame.src = src;
document.body.appendChild(frame);

// Bugfix for Chrome 77 requiring user input before printing
frame.contentWindow.focus();
frame.contentWindow.print();
};

});

</script>

The new KB article suggests modifying the JS source to add PrintJS but you can just add a couple lines to tell the iframe window to print. 

trv.printManager = function () {
   var iframe;
   function printDesktop(src) {
       if (!iframe) {
           iframe = document.createElement("IFRAME");
           iframe.style = "position:absolute; left: -10000px; top: -10000px;";
       }
       iframe.src = src;
       document.body.appendChild(iframe);
       if (window.navigator.userAgent.toLowerCase().indexOf("chrome") > -1) {
          iframe.contentWindow.focus();
          iframe.contentWindow.print();
       }

   }

You saved my time.

Many thanks to @XicoFininho.

Regards,

Ashish Gorana

Thanks @XicoFininho that work like a charm.

(huuu huuuu :)

Joao Rios

If anyone else is using the HTML5Report Viewer and needs to fix their current version for Customers using Chrome 77 without upgrading, you can trigger the iframe window print using the code below. I wasn't able to modify the original JS script so I've done it slightly differently. 

Add this after the ReportViewer is loaded <telerik:ReportViewer ID="ReportViewer1" runat="server" />

<script type="text/javascript">

$(function () {

var frame;
window.telerikReportViewer.printManager.print = function printPdf(src) {

if (!frame) {
frame = document.createElement("IFRAME");
frame.style.display = "none";
}

frame.src = src;
document.body.appendChild(frame);

// Bugfix for Chrome 77 requiring user input before printing
frame.contentWindow.focus();
frame.contentWindow.print();
};

});

</script>

This simply just replaces the existing print function with this modifies version adding the .focus() and .print() calls to the iframe window. This seems to work around the issue where Chromium now requires user input before allowing printing. 

For those who uses HTML Telerik Report Viewer, using 3rd party library Print.js to print document. Replace code inside printDesktop function of telerikReportViewer-x.x.x.x.js:

<script src="/Scripts/Printjs/print.min.js"></script>

trv.printManager = function() {
        //var iframe;
        function printDesktop(src) {
            //if (!iframe) {
            //    iframe = document.createElement("IFRAME");
            //    iframe.style.display = "none";
            //}
            //iframe.src = src;
            //document.body.appendChild(iframe);
            printJS({ printable: src, type: 'pdf', showModal: true });        
        }

...

}();

This way has another benefit: This always display print dialog instead of downloading pdf file as in some web browsers.

Hope this helps!

The simplest of all workarounds is that Ctrl-P in the browser works instead of clicking the print button.

Still not a good solution for many users with this issue.

Also, none of the mentioned code changes work with v12.1.18.824.

To clarify:

<body>

<div>

<telerik:ReportViewer ID="ReportViewer" runat="server"></telerik:ReportViewer>

<script type="text/javascript">

ReportViewer.prototype.PrintReport = function () {

switch (this.defaultPrintFormat) {

case "Default":

this.DefaultPrint();

break;

case "PDF":

this.PrintAs("PDF");

previewFrame = document.getElementById(this.previewFrameID);

previewFrame.onload = function () { previewFrame.contentDocument.execCommand("print", true, null); }

break;

}

};

</script>

</div>

<body>

Hello, to all wondering about a WebForms workaround, this is the solution we've come up with for our implementation. We override the ReportViewer.prototype.PrintReport (as described by Nasko) with the following:

ReportViewer.prototype.PrintReport = function () {

switch (this.defaultPrintFormat) {

case "Default":

this.DefaultPrint();

break;

case "PDF":

this.PrintAs("PDF");

previewFrame = document.getElementById(this.previewFrameID);

previewFrame.onload = function () { previewFrame.contentDocument.execCommand("print", true, null); }

break;

}

};

What this does is overrides it with a nearly identical version of the PrintReport function, with one major difference. If you look at the javascript that is being used by the ReportViewer object, you can see that we the ReportViewer is rendering the report to PDF in an iframe. By reading through some of Telerik's responses, it seems like this PDF is embedded with a command to cause the print, but that's the problem that Chrome has patched out.

What we're doing with this solution is waiting for the iframe to load, and then sending that inner document to print using a browser supported method: execCommand("print", true, null)

We decided to do this because we were also having a problems with the webform workaround adding and moving things in our report. All testing has indicated that this workaround behaves as expected. We just wanted to give this back to the community since, for many of us, the solution of "download the new version and migrate to HTML5 ReportViewer" is simply unacceptable.

The code of PrintAs("Default") prints only the page in the screen. I tried with PrintAs("PDF") but it doesn't work.

Any code to make it work properly for webform reportviewer?

Trying to preview the fix on Demo page, but no report can be rendered on any browser. Please fix it asap.

https://demos.telerik.com/reporting/barcodes-report?&skinName=default

The error I've got from console logs is:

Refused to execute script from 'https://p.adsymptotic.com/d/px/?_pid=16218&_psign=0aa5badf92527f7732e22463d6fa4dbc&coopa=0&gdpr=0&gdpr_consent=&_puuid=b23cc6e3-b486-4f50-a157-c736e4c81836' because its MIME type ('image/gif') is not executable.

This one is not an accepted solution for thousand of end users and hundred of companies that are waiting for your release. Opening the report may be an accepted solution if you are in report viewer and click on print icon, but not when we  want to use direct print ( .PrintMode(PrintMode.ForcePDFPlugin)) for specific reports.

1. The browser will first block this new window from opening automatically like the image below

   2. And  most important the user will have to still click CTRL + P  (after allowing the browser to open this kind of links)

Will this be you final resolution for this issue ? Opening the rendered PDF in a new tab ?

What is the equivalent workaround (by using printMode) for the old Telerik web form report viewer (Telerik.ReportViewer.WebForms.ReportViewer) ? We are using it and hundred of customers are struggling with the print issue. 

We need at least a workaround ASAP.

This really worries me. I am losing confidence in the testing that is being done on these releases. We had to back out the last release because of an issue with defaulting data on grids. Now it appears they are not properly testing new versions of browsers. Like Concept said below, we also love the controls, but they cannot slip on quality. We have hundreds of users using the system, something like this is crippling to us. Telling them to use a different browser (away from their standard) is a low quality answer.

I would not recommend this moving forward but if you need a fix/workaround now. Here is what I did.  I deminified the file telerikReportViewer-##.#.#.###.min.js. Around line 580 you will see the code in the function called "e"

o.body.appendChild(t);

That is the code where the warning/error is thrown. Just after that line add the following code.  This will force the print.

Thank you for working on it. We are eagerly waiting for the fix. Our customers are printing several reports each day and this problem really affects them.

I also have a feedback and I will appreciate if you can share it with your managers. Progress / Telerik is a big company and we expect you to test each version of Chrome vigorously when it is still in beta. Chrome 77 beta version was available almost a month ago, so if you had tested it when it was beta, the fix was going to be ready before the final release.

After every new release of Chrome, we feel very anxious that something in your controls will break with the new version. It happened a couple of times so far, and this really bothers us. I think it also hurts your credibility and our trust on you. You should invest more on testing each new browser version when they are still in beta. You should also test your new versions better. We also had problems with some bugs in your new versions. 

We love Telerik controls and we believe you can take care of this. 

I have been seeing this exact situation with our reports; it appears that it was an intentional functionality change from Google:
https://pdfium.googlesource.com/pdfium.git/+/2021804f1b414c97667c03d7ab19daf66f6a19ef

It indicates that a mouse gesture/event may be required in order to allow the print.  Going to experiment, but that may be of use to some.