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.
"data:application/pdf;base64,BASE64PDFHERE"
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***
Accepted Solution
Pegasystems Inc.
IN
The user's issue is resolved and they have shared the resolution in an email-
"By recreating the data URI issue in straight HTML, we determined it is a Chrome browser issue. Thanks for the assistance."
~Vidyaranjan A V | Community Moderator | PegaProductSupport | Pegasystems Inc.
Pegasystems Inc.
US
I'm sure you have a valid base64 encoding scheme, since you mentioned this works in FF and also in Chrome after a refresh.
But when I did some standalone tests with the attachments you gave, it is showing me the PDF is corrupt. Can you just double check that what you attached is encoded properly?
Pegasystems Inc.
US
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?
NTT Data
US
Rett,
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.
Pegasystems Inc.
US
Hi David,
Thanks for the updated encoding. That one works a lot better ;)
Ok, so going back to my prior diagnostic. What I meant was, when this fails to load. Hit F12. Do you see any errors like this?
If so, double check the markup for your <embed... and what the SRC is trying to reference. In the failure case, is the value either missing, null, or corrupt?
Pegasystems Inc.
US
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.
NTT Data
US
Thanks for the reply. See the attached. I don't see any difference in the DOM when it doesn't load, or when I reload it with the link.
Pegasystems Inc.
US
Thanks for running that diagnostic David. My suspicions were debunked, which in another light, is a good thing.
I no longer suspect something going wrong with retrieving or populating the property reference. Or that Pega has generated invalid HTML.
It really does seem like something is intermittently going wrong with Chrome. While I cannot reproduce it, maybe you can with this standalone test.
Try loading this file (attached) directly in Chrome outside of Pega. (You'll need to rename the file .html because PDN will block it, otherwise)
Do you ever see it reproduce there?
If not, try hosting the file on your app server, and just hitting that URL directly. Does it reproduce here?
NTT Data
US
Thanks for the reply, Rett. I'm seeing the same behaviour in Chrome outside of Pega as inside. This seems to confirm it to be a Chrome issue. Now, what to do about it. Any suggestions?
Pegasystems Inc.
US
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.
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. :)
Accepted Solution
Pegasystems Inc.
IN
The user's issue is resolved and they have shared the resolution in an email-
"By recreating the data URI issue in straight HTML, we determined it is a Chrome browser issue. Thanks for the assistance."
~Vidyaranjan A V | Community Moderator | PegaProductSupport | Pegasystems Inc.