Files directly download from shared links instead of co-editing

[mmeeks]

Describe the bug Someone shares an internal link to a document with me. I click on it, but instead of entering the document I get one of these three behaviors:

1. the file immediately downloads and opens locally - nice but no collaboration / cookie etc.
2. the file-view opens on the folder with the file highlighted but not opening
3. the file fails to load like this: https://github.com/nextcloud/richdocuments/issues/4139
4. the file actually opens corectly.

Chance of getting to 4. is quite a lot lower than it used to be, previously you would get 2. and 4. now I get lots of 1. and 3. as well as 2. - when really I want 4. =)

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Client details:

• OS: Linux
• Browser: Firefox or Chrome

Server details

Nextcloud version: 29.0.7.2

Version of the richdocuments app "8.4.6"

Version of Collabora Online

COOLWSD version: 24.04.8.2snapshot(git hash: 46983cf (E)) LOKit version: Collabora Office 24.04.8.20241020(git hash: 9591bc5) Served by: Ubuntu 22.04.5 LTS Server ID: db11fee2 WOPI host:

[max-nextcloud]

Dear @mmeeks I've been trying to reproduce this for a while and also looked into possible causes with @elzody . The cause we suspected has already been fixed.

Are you still observing this? Could you try and capture a console log and network HAR file when this happens?

[mmeeks]

Can you link to the fix - would love to see what it was, when I debugged this some years ago it seemed like it was a plugin registration / priority order and some randomly ordered initialization.

@pedropintosilva I think we are / were still seeing this on share ? can you chase ?

@max-nextcloud thanks for taking a look !

[max-nextcloud]

Can you link to the fix - would love to see what it was, when I debugged this some years ago it seemed like it was a plugin registration / priority order and some randomly ordered initialization.

That's pretty much spot on: https://github.com/nextcloud/viewer/pull/2486

I'm checking if the fix was actually backported for link shares as well - or rather up to which version.

[max-nextcloud]

In https://github.com/nextcloud/richdocuments/issues/3815 people are still reporting similar behavior up to today. However I fail to reproduce it - which makes debugging extra difficult.

[max-nextcloud]

I'm trying to figure out if this can still be observed somewhere. If it's still happening I will look into writing a debugging patch that at least logs what's going on.

[mmeeks]

This re-occured on our share server the next day - which I believe is a reasonably recent version I think 30.something

[max-nextcloud]

It looks like this is caused by the richdocuments script taking too long to register the handler for the file extension with the viewer. When the file is opened before richdocuments registered the handler it will be downloaded instead.

We used to have the opposite problem of richdocuments trying to register when the viewer script had not been loaded yet and resolved that by moving the viewer initialization into an init script - which means it is included in the html page initially loaded.

https://github.com/nextcloud/richdocuments/pull/4680 reduces the size of the script in question from 10 Mb to 1 Mb (uncompressed). This will speed up the download and processing - but it may still be too slow and depends on network speed etc.

The proper solution most likely would be making the script an init script as well. However we cannot control the order of the init scripts and therefore we cannot rely on OCA.Viewer existing when we are registering our script. One workaround might be to check if OCA.Viewer exists and if it does not create a setter for it on the OCA object that registers the richdocuments handler once OCA.Viewer has been set.

[mmeeks]

I'm still suffering from this (as a fairly intense user ;-) several times per day; I'd really prefer a perfect close of the race window if possible.

I often wonder whether it's a great idea having the file-view etc. underneath COOL, some integrations have a much more naked page (clearly we'd want the goodness of shared dialogs for smart-picker, insert-file etc. still available). But do we truly need to load and render a directory view underneath the COOL iframe ? =) Would having direct links let us load files quicker and avoid some of these issues ?

Then again it doesn't help for folder loading and then clicking on files which is also a problem so ... ;-)

[max-nextcloud]

@mmeeks I'm still wondering why this happens multiple times a day for you. I'd assume the script is cached after the first load.

• Do you happen to have caching disabled in the browser?
• Could you check in the browser dev tools Network tab if the richdocuments-viewer.js is loaded from the cache?

(sorry for the german language screenshot)

[mmeeks]

Hi @max-nextcloud what help would be to provide a cheat-sheet on data you need to debug this, so on a day/time when I see the issue - which is intermittent - and also have time to investigate I can follow the steps and provide everything you need :-) also I'm aware that my Nextcloud is already old (most are given the pace of improvement :-) and may not have whatever fixes are already deployed. Anyhow - happy to go over this, but I can promise you - if there is a known-race, I will hit it somehow ;-)

[ferdiga]

I encounter the same problem.

documents in a shared folder from one Hetzner storage share on another Hetzner storage share fail to open.

• "Loading" for a while + and fails to load

[juliusknorr]

@ferdiga Your issue sounds totally different. I suggest to check with our provider in this case as it sounds like a setup related problem.

[mmeeks]

Thanks so much for getting to this, will try to get it deployed and check it out soonish.

[mmeeks]

This has recently got a lot worse with the upgrade to include the fixes I think - more details here: https://github.com/nextcloud/richdocuments/issues/3815#issuecomment-3394089979