SR-B13458 (Data URI base64 PDF not loading in Chrome)
I have a control which is creating an <embed> using data URI to display a base64 PDF in a screen. The PDF renders but only after refreshing the screen. The PDF display is not visible when switching tabs until refreshing the screen again. This works correctly in Firefox. Chrome version is 55.0.2883.87 m.
Steps to Reproduce
Create a control with this logic.
<div><embed id="previewframe" name="previewframe" src='<p:r n="$this-value" />' width="100%" height="400" type="application/pdf"></div>
Create a text property which references this control.
Create a section and use the property.
Sample base64 PDF is attached. Error Message
None Attempted Solutions
Used an iframe and referenced the PDF from ServiceExport folder, but this downloads the PDF to the client's machine. Due to the nature of the PDF contents, we don't want the PDF downloaded automatically when viewing. We also do not want the Users to have to change their browser settings.
***Updated by moderator: Lochan to add SR Exists group tag***
My previous comment still stands, as I cannot get your base64 encoded attachment to work. However, I don't think that is your issue, which was also implied by the previous statements. I just difficulty with using your data as source sample. I did other tests with my own PDFs in the meantime.
I have a theory right now, based on the visual representation of your failure. It appears to indicate the browser was not able access the resource location. I would run a couple diagnostics.
When this fails the first time, check your console. Do you see errors with not being able to acccess the resource? If yes, then subsequently check what the value is on the DOM. It is likely the property reference was not resolved properly.
Then when you refresh and get it to work, is the base64 encoded value now populated on the DOM?
Thanks for the reply. I've attached a fresh copy of the base64 PDF. I'm not sure what you mean by checking the console. As I've continued testing this, it is displaying randonly, sometimes the first time, other times only after refreshing the section. It loads every time in FF.
Slight update to my last diagnostic. Whether or not you see that error, check the generated markup in the DOM explorer using F12. I suspect your SRC is null and for unknown reasons the property reference was not resolved properly.
Awesome. This is good news. I'm not just saying that because I was able to show Pega does not have a defect here. But we now have a really good standalone test we can hammer at repeatedly (and with ease) and more importantly you can share with relevant support groups.
I too, can now reproduce this with my standalone test stub, outside of Pega and outside of hosting this in an app server. If I spam enough refreshes I too, see the same issue. Upon close inspection, all of the data is still there. (It kind of has to be at this point, because I hard coded the HTML to include your base64 encoding. There are no external references, not even local files)
To further prove this point, when I see it show up blank, I am able to right click the embed area and download the fully functional PDF file.
So it is really only a visual rendering problem. Nothing about this is corrupt, except the visual representation of the <embed> entity.
I would recommend engaging Google support for this. At this point, you can/should scrub your PDF to remove any sensitive information. Just make a "hello world" test PDF, so the base 64 encoding is even smaller. Who knows, maybe in doing so, you'll find out the "size" of the PDF helps reproduce it as it grows larger.
I went ahead and gave you another independent sample for this purpose. It looks like "size" is unrelated, as this souce PDF is very basic and small.
One thing I did notice about FF vs Chrome is that during refreshes FF maintains the outer "shell" or "frame" to house the PDF and basically only reloads the inner PDF. Chrome appears to try to re-render the entire <embed> over and over. So maybe their own implementation of how to handle this scenario is not the most ideal or robust.
These are all theories at this point. Good luck. :)