APP_RENDERING_FAILED

[Robert5DE7]

Is this the right place for a Feature Request 🙂

If a pdf fails to load/render an event type 'APP_RENDERING_FAILED' is fired but there is no indication of why it failed.

It would be useful to at least know if it failed becuase the file wasn't found or access was denied or it was corrupt and failed to parse/render.

This would help support to deal with users.
 

TIA

Rob

[Joel Geraci]

You'll get a different error if the file couldn't be loaded at all. If the file was found and is being read, you'll get the DOCUMENT_OPEN event. What I've noticed is that page one will display well before APP_RENDERING_DONE fires, so again, you know the file had been parsed at least to the degree that page one can be shown. I think you can take APP_RENDERING_FAILED for exactly what it is. Some part of the file couldn't be rendered. 

[Robert5DE7]

I tried intentionally setting the wrong url on AWS, I can see from the console this returns a 403 (Forbidden) which is as expected.

The events triggered are PDF_VIEWER_OPEN  > APP_RENDERING_START  > APP_RENDERING_FAILED

The last event fired with a code of "PREVIEW_RENDERING_FAILED".

So yes you are right, there is no DOCUMENT_OPEN in this case.

Slightly surprising is the xhr failed even before even the  PDF_VIEWER_OPEN was logged.

I guess I can track the various stages to discover if the file wasn't loaded as you imply, though it would still be nice if they could just have it as part of the failed event.

Thanks

Rob

[Joel Geraci]

For what it's worth, in practice, I never use location:url to load the PDF. Instead, I use fetch, convert the result to a ByteArray and then pass that as a Promise to the location. This solves a few problems. First, I know if the PDF can be located and loaded. Second, I can easily load PDf files from other domains without having to play with CORS. And finally, I can have my own loading screen for large PDF files. 

[Robert5DE7]

That's an interesting idea, definitely seems worth implementing.
Will do that.

Thanks
Rob