Can you reproduce using one of our samples or online demos?
Are you using the WebViewer server?
Does the issue only happen on certain browsers?
Is your issue related to a front-end framework?
Is your issue related to annotations?
Do you have any recommended cache headers to set for the statically served WebViewer assets (i.e. JavaScript, CSS, and fonts under the lib/ directory)? If we were to aggressively cache these, would the cache inherently be broken across WebViewer client upgrades?
I don’t think we have any recommended cache headers. There have been a few cases where certain full API methods become unavailable due to caching the worker files and the pathing to fetch them: Unknown action from worker: GetPDFDoc when using WebViewer within PWA. Although it may depend on how this is done.
I would perhaps cache with query strings to denote the version so that changing versions will cause the newer files to get cached instead.
@Andy_Huang, how are we able to configure WebViewer to append a unique query string to the assets it loads? From what we can tell, we are only able to configure a path option.
Are you referring to the scripts referenced in the embedded iframe (public/ui/index.html)?
We just copy those over from node_modules/@pdftron/webviewer in the current state of our Next.js application build, and I don’t see a straightforward way of appending query parameters to those assets outside of applying processing to that HTML file. Is that how you typically see users doing this?
For additional context, deploying a new WebViewer version is causing issues for some of our users due to browser asset caching. For example, affected users experience at least this error:
We are looking for a solution that breaks the WebViewer asset cache across version upgrades. Otherwise (across other application deploys in which WebViewer is not upgraded), it seems to make sense to aggressively cache these unchanged assets.