Log in to start a topic

AR 14 JSViewer - Sticky PREPARING PRINT... overlay on Chrome

Posted by: ricardo.pereira on 21 September 2020, 3:55 am EST

  • ricardo.pereira

    • Post Options:
    • Link
      Copy

    Posted 21 September 2020, 3:55 am EST

    Hi,

    We are using AR14 JSViewer and we found out that there was a bug when printing a report using it’s native functionality.

    Printing on Firefox works well even though we get a random log on the console with the following message: “PDF e8b68c6f31620043965edaadef26b51f [1.4 ActiveReports 14 / ActiveReports 14] (PDF.js: 2.6.123)”.

    The problem is when we try to print on Chrome. The same blue overlay with the text “Preparing Print” appears then the print dialog, but after we perform an action on that dialog (either cancel or print), the blue overlay doesn’t fade and we end up with the following error on the console:

    
Uncaught DOMException: Blocked a frame with origin "https://<domain>" from accessing a cross-origin frame.
    at HTMLIFrameElement.a.onload

    Do you have any suggestion? Thanks in advance.

    Best Regards,

    Ricardo Pereira

  • mohitg

    Posted 21 September 2020, 3:53 pm EST

    Hello,

    I am not able to replicate the issue at my end using the sample at the following link:

    https://github.com/activereports/WebSamples14/tree/master/JsViewerSamples/JSViewer_MVC

    Chrome Version: 85.0.4183.121

    Could you please check with the above sample and check if the issue is reproducible at your end or not. If not, could you please share the stripped down sample so that I can able to replicate the issue at my end.

    Thanks,

    Mohit

  • ricardo.pereira

    Posted 23 September 2020, 1:59 am EST

    Hi Mohit,

    Using that sample I had no issues.

    After some further investigation I noticed that the problem lies on the “jsViewer.min.js” file. I don’t know which version you used but here are the steps to replicate:

    Base configuration:

    Test 1 (working well):

    • Use “@grapecity/ar-viewer@14.0.1483” to run the report then click on the print button. This will work opening the report on an iframe in a new tab and also the print dialog.

    Test 2 (not working and throwing the initially reported error):

    • Use “@grapecity/ar-viewer@14.2.2530” to run the report then click on the print button. This will throw the error “Uncaught DOMException: Blocked a frame with origin “https://” from accessing a cross-origin frame.

      at HTMLIFrameElement.a.onload” even though the print dialog will also appear. But the “Preparing Print” won’t fade preventing every further action.

    Attached is a sample website with the broken jsViewer.min.js version already included. I can’t provide an api but I guess you’ll have one for this testing cases.

    The only thing you’ll have to do is modify the file “app\Views\Home\Index.cshtml” by replacing the “reportService” url and the “REPORT_NAME.rdlx” with your report.

    Hope this helps you sort this issue.

    Best Regards,

    Ricardo Pereiraapp.zip

  • mohitg

    Posted 24 September 2020, 4:44 am EST

    Hello,

    I am able to reproduce the issue. I have escalated the issue to the development team (AR-25176) and will inform you once I get any updates from them.

    Thanks,

    Mohit

  • ricardo.pereira

    Posted 24 September 2020, 7:31 pm EST

    Hi Mohit,

    Thank you, I’ll keep checking this thread.

    Best Regards,

    Ricardo Pereira

  • mohitg

    Posted 25 September 2020, 1:41 am EST

    Hello,

    This is a bug in new JsViewer. Can you use the Old JSViewer (@grapecity/ar-viewer@14.0.1483) as workaround for time being.

    Thanks,

    Mohit

  • paul

    Posted 24 October 2020, 3:06 am EST - Updated 30 September 2022, 7:44 am EST

    I am getting exactly the same problem with AR14 Pro vs 14.2.20530 in a DotNET Core (3.1.8) web application. On exiting the Print dialog (either after having printed a document or by clicking the [Cancel] button) the “Preparing print…” modal dialog remains on-screen with no way of clearing it other than a total page refresh.

    Do you have a temporary fix that I can use?

    Kind regards,

    Paul

    896×637 44.9 KB

  • mohitg

    Posted 25 October 2020, 2:12 pm EST

    Hello,

    Currently it is with developer team and will inform you once it is fixed.

    Do you have a temporary fix that I can use?

    You can use the old version of JS (@grapecity/ar-viewer@14.0.1483) as workaround for time being.

    Thanks,

    Mohit

  • mohitg

    Posted 9 December 2020, 7:15 pm EST

    Hello,

    Could you please check with the latest version of AR14.2:

    http://cdn.grapecity.com/ActiveReports/AR14/Hotfixes/ActiveReports-v14.2.20717.msi

    Thanks,

    Mohit

  • rgreen

    Posted 2 April 2021, 12:51 am EST

    Hi Mohit,

    I am getting this issue with Google Chrome and JSViewer 15.0.3

  • mohitg

    Posted 2 April 2021, 3:23 am EST

    Hello,

    Can you please share the steps to reproduce the issue as I am not able to replicate the issue.

    Thanks,

    Mohit

  • mohitg

    Posted 2 April 2021, 3:27 am EST

    Also, Can you try with the latest build of AR. You can download the same from the following link:

    https://www.grapecity.com/activereportsnet/download

  • rgreen

    Posted 2 April 2021, 4:48 am EST

    I am using ActiveReports 15.0.5.0. It looks like the same issue that Ricardo was getting earlier. I get the message “Uncaught DOMException: Blocked a frame with origin “https://” from accessing a cross-origin frame.

    at HTMLIFrameElement.a.onload”

  • rgreen

    Posted 2 April 2021, 4:48 am EST

    I am using ActiveReports 15.0.5.0. It looks like the same issue that Ricardo was getting earlier. I get the message “Uncaught DOMException: Blocked a frame with origin “https://” from accessing a cross-origin frame.

    at HTMLIFrameElement.a.onload”

  • mohitg

    Posted 4 April 2021, 4:19 pm EST

    Hello,

    I have tried with the same application as attached in the following forum post:

    https://www.grapecity.com/forums/ar-dev/ar-14-jsviewer---sticky-pr#hi-mohit-using-that-sample

    However, I am not able to replicate the issue. Could you please share the stripped down application so that I am able to replicate the issue at my end.

    Thanks,

    Mohit

  • rgreen

    Posted 6 April 2021, 3:20 am EST

    ReportApp.zip

    Here is my sample project.

  • mohitg

    Posted 7 April 2021, 9:19 pm EST

    Hello,

    Thanks for the sample.

    I am able to reproduce the issue and have escalated the issue to the development team (AR-26364) and will inform you once I get any information from them.

    Thanks,

    Mohit

  • mohitg

    Posted 8 April 2021, 7:13 pm EST

    Hello,

    Please add dependency from System.Text.Encoding.CodePages NuGet package and add code in program.cs:

    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

    Thanks,

    Mohit

  • rgreen

    Posted 15 April 2021, 8:08 am EST

    Hi Mohit,

    I added that package and code, however I am still getting the sticky “Preparing Print” overlay.

  • mohitg

    Posted 22 April 2021, 5:03 am EST

    Hello,

    Can you please check after upgrading to the latest version of JsViewer and AR .i…e AR15.1

    https://www.npmjs.com/package/@grapecity/ar-viewer

    Also, update the AR assemblies to AR15.1.0.

    Thanks,

    Mohit

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.