We are in the process of making access to our support ticket system available via our app so that clients can track their tickets and progress and so that it is easier for us to manage our support tickets.
The above being said, we have run into a couple of challenges, i.e. :
Is it possible to open the HTML component so that it takes up the visible space in the view i.e. the content window (see screenshot 1 below).
Using the fullscreen option not only interferes with our view but also is another click that we would rather not have to make.
It also means moving closing fullscreen before being able to navigate back and forth in the app.
Then there is the ugly initial render in a small box which often looks like there was a load error of sorts;
We also tried using a simple client side library ObjectPDF to render pdf attachments, this threw out a sandboxing error, as did using our own iframe, embed or object elements. (incidentally using a journey document URL for the source in all cases) (see screenshot 2 (below);
As a last ditch effort we tried simply opening the browser with the pdf url, and got a further error that the allow-popups permission was not set on the iframe. (see screenshot 3 below).
Any advise or pointers in this regard would be greatly appreciated.
Is it possible to open the HTML component so that it takes up the visible space in the view i.e. the content window (see screenshot 1 below).
Not possible. Please suggest this as well as “toggle HTML fullscreen from JS/TS” to our Product Roadmap for future consideration
We also tried using a simple client side library ObjectPDF to render pdf attachments, this threw out a sandboxing error, as did using our own iframe, embed or object elements. (incidentally using a journey document URL for the source in all cases) (see screenshot 2 (below);
As a last ditch effort we tried simply opening the browser with the pdf url, and got a further error that the allow-popups permission was not set on the iframe. (see screenshot 3 below).
Our platform team will respond with a more detailed explanation of the limitations of the HTML component as it relates to this type of sandboxing issue.
In the mean time, for PDFs, you can render them in the Application runtime using standard JourneyApps components. If the attachment is already in the App DB you can just use journey.files.viewFile(attachment) and if the PDF is behind some URL then you can use this solution
In general, you typically cannot simply embed another web app inside of the HTML component by simply pointing the HTML to the specific URL (details on limitations to follow), and so in your specific case you will likely be better served by doing a integration to your ticketing system and using standard JourneyApps component to display the results / response from the integration with the ticketing system.
@matthew Regarding the sandboxing errors - the content you are trying to display in the iFrame is likely restricted. Please see this new entry in our developer docs for a list of content restrictions that have been lifted in the JourneyApps iFrame Client. Any other content will result in an error.
You will notice that allow-popups is not included, hence you are receiving the error in screenshot 3. A similar issue is occurring in screenshot 2 - to display PDFs the sandbox would need to include allow-popups-to-escape-sandbox (reference), which is not currently supported by the JourneyApps iFrame Client.
@Tielman, Martin had a similar idea and is passing the images and pdf documents from the component back to the Journey file viewer to display in the app. It does make more sense than re-inventing the wheel in the component itself. It also keeps in line with user expectations in terns if consistency of presentation.
@Benita, thank you for the explanation. I understand the need for security, but perhaps on some of the items that Journey is prepared to be flexible on the developer could include those as properties on the HTML XML component on the view to either further restrict or relax the iframe attributes.
@matthew Noted, thanks for the feedback! I’ll go ahead and log this for future consideration - to allow developers to further restrict or relax iFrame sandboxing restrictions if feasible from a security perspective.
