I build a custom version of the web-viewer UI based on the Github repo. After merging in the latest bunch of commits (listed at the end of this post), I suddenly found that when trying to load an offline version of my file I get an error “Error received return status 0” in the UI. In the browser console I see:
VM41298:1 GET blob:http://localhost:8100/8736053f-5cf1-4f70-8cc7-abae820fd5e9?_=4 net::ERR_FILE_NOT_FOUND
The code that I am using to load my offline file has not changed. It is simply:
self.webViewer.loadDocument(objectUrl, { filename: fileName, streaming: true });
So it looks like something in one of the commits listed below has broken this functionality. I confirmed this by reverting back to my custom build prior to merging in these commits. The error went away.
-
[Update] Added accessibility labels (#1924) …
webviewer-ui committed yesterday
67123c3
-
Feature/theme changed event (#1972)
webviewer-ui committed yesterday
4c0de88
-
[feature] Locally mimicking Circle CI (#1704)
webviewer-ui committed yesterday
00c0293
-
[Bugfix] file attachment icon was a circle in the notes panel (#1969)
webviewer-ui committed yesterday
ce5f12c
-
Persist pending comments/edits (#1930)
webviewer-ui committed yesterday
9d2cfd4
-
sync ui master with webviewer master
ZhijieZhang committed 2 days ago
Where is your forked github repo?
Sardor Isakov
Software Developer
PDFTron Systems, Inc.
www.pdftron.com
Those changes are for the UI side of WebViewer. Would you be able to share error message or error trace? Is it coming from CoreControls.js or webviewer-ui.min.js?
Sardor Isakov
Hi Sardor,
I have updated to the latest commits and am still getting the error. The stack trace is copied below. It seems to be something to do with the streaming option. I set this on the fly depending on whether we are getting the file from local storage or accessing using range requests from the server. We have been doing this for a long time - it only fails if I update to the latest commits in the web viewer-ui repo.
CoreControls.js:formatted:5911 Uncaught (in promise) Error received return status 0
ia @ CoreControls.js:formatted:5911
Promise.then (async)
y @ CoreControls.js:formatted:5918
ea @ CoreControls.js:formatted:5902
Promise.then (async)
y @ CoreControls.js:formatted:5918
(anonymous) @ CoreControls.js:formatted:5920
aa @ CoreControls.js:formatted:5899
h.rx @ CoreControls.js:formatted:7895
loadDocument @ webviewer-ui.min.js:50
cy @ webviewer-ui.min.js:50
(anonymous) @ webviewer-ui.min.js:50
loadDocument @ webviewer.min.js:1
(anonymous) @ file-viewer.page.ts:690
wrapped @ raven.js:376
invokeTask @ zone-evergreen.js:391
onInvokeTask @ core.js:34182
invokeTask @ zone-evergreen.js:390
runTask @ zone-evergreen.js:168
invokeTask @ zone-evergreen.js:465
ZoneTask.invoke @ zone-evergreen.js:454
timer @ zone-evergreen.js:2650
setTimeout (async)
scheduleTask @ zone-evergreen.js:2671
scheduleTask @ zone-evergreen.js:378
onScheduleTask @ zone-evergreen.js:272
scheduleTask @ zone-evergreen.js:372
scheduleTask @ zone-evergreen.js:211
scheduleMacroTask @ zone-evergreen.js:234
scheduleMacroTaskWithCurrentZone @ zone-evergreen.js:1107
(anonymous) @ zone-evergreen.js:2686
proto. @ zone-evergreen.js:1428
(anonymous) @ raven.js:1133
(anonymous) @ file-viewer.page.ts:686
invoke @ zone-evergreen.js:359
onInvoke @ core.js:34201
invoke @ zone-evergreen.js:358
run @ zone-evergreen.js:124
(anonymous) @ zone-evergreen.js:855
invokeTask @ zone-evergreen.js:391
onInvokeTask @ core.js:34182
invokeTask @ zone-evergreen.js:390
runTask @ zone-evergreen.js:168
drainMicroTaskQueue @ zone-evergreen.js:559
invokeTask @ zone-evergreen.js:469
invokeTask @ zone-evergreen.js:1603
globalZoneAwareCallback @ zone-evergreen.js:1629
I’ve investigated this problem further and I can see that the problem seems to be with the Blob objectUrl. My objectUrl looks like this: blob:http://localhost:8100/a2ef9bda-29ae-403d-b8ed-6a561a9655df when I call self.webViewer.loadDocument(objectUrl, { filename: fileName, streaming: true });. But then I see an error in the browser network tools with a URL that looks like this: blob:http://localhost:8100/a2ef9bda-29ae-403d-b8ed-6a561a9655df?_=33. If I click on the URL from the network tab it tells me that the file cannot be found. If I remove “?_=33” from the objectUrl in the network tab and paste it into a new browser window it is able to download a copy of the file for me. So what is causing the extra characters to be appended to the objectURL?
Hi Sardor,
I’ve spent a lot of time trying to sort this out today. I reckon that this problem is related to the problem that I have reported in this ticket: https://groups.google.com/g/pdfnet-webviewer/c/o9ItOwYfbZg/m/6pLXMODrAwAJ
I believe that something has changed in being able to set the streaming parameter when calling loadDocument.
Previously my code to load a local file was: self.webViewerInstance.loadDocument(objectUrl, { filename: fileName, streaming: false }); (as per https://groups.google.com/g/pdfnet-webviewer/c/Mo1DVAAWb2I/m/Yr3CpaclBwAJ).
However, today I found the following in the typescript definitions for the loadDocument method:
So it seems that the parameter now needs to be passed as part of an xodOptions object. So I’ve updated my code to load a local file to the following:
private localXodOptions = { streaming: true, startOffline: true };
private serverXodOptions = { streaming: false, startOffline: false };
…
self.webViewerInstance.loadDocument(objectUrl, { filename: fileName, xodOptions: self.localXodOptions });
However that doesn’t actually help. I still get the same error and the same problem with extra characters being added to the objectUrl.
My code to load local files has been working for a long time, so something seems to have changed on the WebViewer side. I really need to get this sorted out. Any assistance or direction that you can provide would be appreciated. I’m happy to do a remote screen sharing session if that helps. I have done that in the past with Justin and it helped us to resolve an issue that was hard to track down via email.
Kind regards,
David
Hi Sardor,
Any progress on this issue - it is really holding me back.
Kind regards,
David
I sorted this out. I removed any reference to streaming in my loadDocument call and it now works OK. The change in your code that broke things for me was in loadDocument.js, extractXodOptions. What used to be:
xodOptions.streaming = options.streaming === ‘true’;
was changed to:
xodOptions.streaming = options.streaming === ‘true’ || options.streaming === true;
I had been passing “streaming: true” to loadDocument.
I’m not really sure why this broke things, but I found that by not setting the streaming option it all now seems to work OK. I’m also not sure why I no longer need to set the streaming option to true for offline files - in the past I needed to.
I’ve got a little more testing to do, but at this stage all seems to be working.
Regards,
David
Hi, David
I apologize for the delay, I investigated this further, and we did reproduce this. The fix is in the progress and it will be ready in a couple of days once it passes tests, I’ll provide a link to download the patched latest version.
Sardor
So upon testing in my iOS app (Ionic) I find that I do need the streaming option. So I will definitely need your fix. The sooner the better as I need to get out an update and cannot do so until that issue is resolved.
Hello David,
You still should be able to use streaming in loadDocument, just use the old way of using the flag, like instance.loadDocument(…, { streaming: true }).
Regarding the xodOptions.steaming: true option loadDocument, it looks like our documentation was not clear or not updated on time, and the patch for this issue is in progress and it will be available soon. And I’ll let you know when it is ready. I’ll post the link to download the patched version as soon as it is passing all the tests and ready.
Let me know if this works for you?
Sardor Isakov
Software Developer
PDFTron Systems, Inc.
Yes please provide the link to the patch as soon as possible.
Hello Sardor,
Is this the fix that you are talking about? https://github.com/PDFTron/webviewer-ui/commit/89491bca109d1b56ecc5b19cf52866fd0f8af8e9. I found that on the 7.1 branch. My fork is based on the master branch.
I don’t see how that fix is going to help me anyway. I get the error that I am trying to get your help to resolve using instance.loadDocument(…, { streaming: true }).
I really feel like we are going around in circles on this issue without getting anywhere. Could we have a phone call or a remote session to resolve this?
Kind regards,
David
Hello Sardor,
Zhilje told me today that I need to switch from building my custom UI from the master branch to the 7.1 branch. This seems to have fixed the problem that I was having.
I’m a bit annoyed because this has wasted a lot of my time (and probably your time as well). I don’t ever remember being advised that the master branch had become experimental. Maybe I missed an email.
Kind regards,
David
I spoke to soon - the problem is still occurring. I now have a ticket in the support desk where this issue is being dealt with: https://support.pdftron.com/helpdesk/tickets/17587
I apologies for delay, the changes needed some testing and it took some time, here is download link from nightly server http://nightly.pdftron.com.s3.amazonaws.com/stable/2020-10-30/WebViewer-7.1.2_2020-10-30_stable.zip this build has update to loadDocument doc and API itself. These are commits to Github repo if UI https://github.com/PDFTron/webviewer-ui/commit/4251239d019a740243b06b739fd1b7f4f2591bd7
Sardor Isakov