Files sometimes do not get opened immediately on internal links

[juliusknorr]

Steps to reproduce

1. Have an internal link like /f/1234
2. Open it in a browser (e.g. from clicking in an email)

Expected behaviour

The file should open

Actual behaviour

Sometimes the file doesn't open automatically and there is an error thrown. It seems happening more often with cleared browser cache.

Now the odd thing here is that the error is thrown before the viewer app is initialized, so there seems to be some kind of timing issue when trying to get the file actions for the requested file.

nextcloud/server#45586 would help with the error but I cannot see how it would solve the file then just not opening up.

I have not managed to reproduce this locally on any of the versions, but tech-preview is affected (currently on 29.0.0) and another instance on 28.0.6 (both should be upgraded 🙈 )

@susnux Do you have any idea on why the order in which the handleOpenFile and the viewer registrations would be executed might differ?

[juliusknorr]

Upgraded the 29 instance to 29.0.3, still reproducible sometimes, but now without an error

Edit: Still one for the sidebar:

[pedropintosilva]

cc'ing as requested: @mmeeks @karlitschek

[bentuna]

We are running 28.0.8 and can still confirm the issue is happening sometimes.

[juliusknorr]

I had a chat with @susnux about this and this seems to be a design flaw of the viewer api registering the file type handlers too late. He will think about a possible workaround.

[juliusknorr]

@susnux I looked a bit further into it while fixing a regression with 30 nextcloud/server#47014

I still have not managed to trigger this race condition locally. I tried to think about a way to fake this timing issue but cannot figure out how I could manually delay the viewer registration like it is happening on those affected systems. But thought about a workaround like this, kind of deferring the handleOpenFile until the DOMContentLoaded event from viewer has registered the file actions.

diff --git a/apps/files/src/components/FilesListVirtual.vue b/apps/files/src/components/FilesListVirtual.vue
index 233353d0985..62cc53fd093 100644
--- a/apps/files/src/components/FilesListVirtual.vue
+++ b/apps/files/src/components/FilesListVirtual.vue
@@ -209,7 +209,7 @@ export default defineComponent({
                const { id } = loadState<{ id?: number }>('files', 'fileInfo', {})
                this.scrollToFile(id ?? this.fileId)
                this.openSidebarForFile(id ?? this.fileId)
-               this.handleOpenFile(id ?? null)
+               this.handleOpenFileOnLoad(id ?? null)
        },

        beforeDestroy() {
@@ -242,6 +242,18 @@ export default defineComponent({
                        }
                },

+               handleOpenFileOnLoad(fileId: number|null) {
+                       // This is a workaround as the viewer api registers file actions too late
+                       // Some might not be ready yet
+                       if (document.readyState === 'complete') {
+                               this.$nextTick(() => this.handleOpenFile(fileId))
+                       } else {
+                               window.addEventListener('load', () => {
+                                       this.$nextTick(() => this.handleOpenFile(fileId))
+                               })
+                       }
+               },
+
                /**
                 * Handle opening a file (e.g. by ?openfile=true)
                 * @param fileId File to open
                 * 

[susnux]

kind of deferring the handleOpenFile until the DOMContentLoaded event from viewer has registered the file actions.

This I would say makes sense, though it would cause visual delays on slow connection. But should be a good fix.

[mmeeks]

Thanks Julius - this plagues me many times per day =)

[pedropintosilva]

Hello and thanks for the nextcloud/viewer#2486 @susnux! I see that @artonge has tried to backported with nextcloud/viewer#2490 to [stable29] but it seems there is the need to rebase it and there are some conflicts. If there is anything I can test please let me know.

[pedropintosilva]

Thanks @artonge , I see it's not in! Good so it should be include in 28 and 29 release. The fix is include 3.0.1 (17 oct).

@AnnaNazaryan : (to be confirmed) it seems in our staging it's still reproducible (30.0.2 RC1) cc: @jazevedo-coll

[jazevedo-coll]

(to be confirmed) it seems in our staging it's still reproducible (30.0.2 RC1)

@pedropintosilva what I have seen with our staging instance is: when opening an internal link on a browser with a clean cache and history and site settings, sometimes the file will not open and will just download instead.

[mmeeks]

Is it possible that there is some async / defer / fetchpriority foo going on that sometimes perturbs the order of execution and initialization of the different JS modules themselves ?