after closing a document the current directory is lost

[wdehoog]

After closing collabora-online the current directory is lost and the user is back in it's home directory.

The address bar shows:

Before opening:
../nextcloud/index.php/apps/files/?dir=/X/Y&fileid=16766

While editing:
.../nextcloud/index.php/apps/files/?dir=/X/Y&fileid=16766

After closing:
.../nextcloud/index.php/apps/files/?dir=/&fileid=104

Client details:
firefox

Server details

Web server:
Apache 2.4

Database:

PHP version:

Nextcloud version:
16.0.4

Version of the richdocuments app
3.4.2

Version of Collabora Online
4.0.6

[gary-kim]

I can confirm that this is an issue.

[juliushaertl]

I cannot reproduce that. @gary-kim Are you also on 16? Does it always happen? It could be some race condition with the file list reload and history handling that is done on close.

[gary-kim]

Yes, I'm on 16. It always happens but sometimes, it still loads the correct contents of the directory while losing the directory path. So the breadcrumb will show root but the directory contents will be for the directory you were in.

EDIT: Forgot to mention. I'm on Firefox, running richdocuments 3.4.2. I usually use a stable version of Libreoffice Online I compile but I have confirmed the issue also occurs with CODE.

[tk7936]

I have the same Problem but on Edge not Firefox, On Firefox it works fine for me. Very annoying for my Edge Users. Basically it happens file independent, your in a sub directory and once the document is closed it jumps back to the root directory, so you have to click through the hierarchy to get back where you were everytime. :(

[andrem1987]

We have the same Problem. We are running Nextcloud 16.0.5, richdocuments 3.4.2 and Collabora 4.0.6.

[manu-p]

Same here with FF, but not with Brave nor Chromium, on Ubuntu 18.04
NC 16.0.5 + Collabora Online 3.4.3

[tk7936]

It has started on Firefox for me as well now. It started after update to FF 70.0.0. Now Chrome is the only Browser still working. Im in big trouble if it fails there to. Hope it wasnt a mistake to trust in Nextcloud.

[xtrasimplicity]

Same issue here, with some browser combinations. Not sure why, exactly. Will investigate further when I get a moment. 👍

[g4rf]

We have two installations of Nextcloud on different servers: One with this issue, the other one not. They have nearly the same configuration and apps, the biggest difference: The working one runs on Apache with HTTP/1.1, the buggy one on Nginx with HTTP/2.0.

I did a check in the network analysis of the developer tools of Firefox and there is a difference in the http calls: The buggy one does a double request to the root directory after closing the document.

code: 207
type: PROPFIND
address: https://*****.de/remote.php/dav/files/theuser/

The working one sends this request only one time and to the right sub-directory, not the root directory.

Hope, that'll help. If you need more information I'll try to provide more.

[xtrasimplicity]

It looks like this is a Firefox issue, not a HTTP1.1/2.0 issue. I've posted the headers for the AJAX requests that are triggered when File > Close Document is clicked.

Firefox (Broken)

PROPFIND /remote.php/dav/files/username/folder/ HTTP/1.1
Host: ...
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
requesttoken: .....
Depth: 1
Content-Type: application/xml; charset=utf-8
Content-Length: 621
Origin: https://.......
Connection: keep-alive
Cookie: ...
Pragma: no-cache
Cache-Control: no-cache

PROPFIND /remote.php/dav/files/username/ HTTP/1.1
Host: ....
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
requesttoken: ....
Depth: 1
Content-Type: application/xml; charset=utf-8
Content-Length: 621
Origin: https://...
Connection: keep-alive
Cookie: ....
Pragma: no-cache
Cache-Control: no-cache

When using Chrome, as noted by @g4rf above, there's only single XHR request to the parent directory rather than one to the parent directory and one to the user's home directory.

[xtrasimplicity]

Interestingly, it looks like Collabora is detecting Firefox as a mobile client. When closing a document in Firefox, callMobileMessage('close') is called (defined in https://github.com/nextcloud/richdocuments/blob/37a7c7372105bdc4ee888b0c62a18ab5780e0553/src/helpers/mobile.js), but is not called when using Chrome*.

* I'm sure of this, as callMobileMessage's function definition logs to the console and there's nothing logged to the console regarding this (on Chrome):

const callMobileMessage = (messageName, attributes) => {
	console.debug('callMobileMessage', messageName, attributes)
        ....
}

It looks like it's triggering both the Close_UI and close messages, rather than halting the execution chain after the Close_UI call - hence, the two XHR requests. Logically speaking, it should just be a case of adding a return statement after the call to callMobileMessage('close')`, but I'll need to test it out.

Edit (14/11/2019): Scratch that. Chrome doesn't log debug-level messages by default. These methods are in fact called the same on Firefox and Chrome. Back to the drawing board! :/

[tk7936]

I do have this Problem on edge also, not sure if that means its the same code issue.

[xtrasimplicity]

After logging all XHR requests and the current URL prior to the request, with the JS below, it's appears that the issue isn't actually with the Collabora implementation, but rather something with NextCloud itself.

 var old = XMLHttpRequest.prototype.open;
    XMLHttpRequest.prototype.open = function(method, url) {
      console.log("Starting ", method, "request to: ", url, ". Current URL is ", location.href);

      old.apply(this, arguments);
    };

When closing a document with Firefox, the following is printed to the console:

Whereas when closing a document with Chrome, the following is printed to the console:

On Firefox, after the first PROPFIND request, the current URL is changed to /app/files/?#, which then forces the user's home directory to be loaded (hence the subsequent PROPFIND request).

On Chrome, the user is never redirected to /app/files/?#, so the user's home directory isn't loaded.

When updating the JS above to include a debugger call before the XHR request, the following call stack can be seen.

Will investigate further when I get another moment.

[g4rf]

When using Chrome, as noted by @g4rf above, there's only single XHR request to the parent directory rather than one to the parent directory and one to the user's home directory.

To make it clear: I used the same Firefox (actual version on Ubuntu) to test the two nextcloud setups. On the Nginx one it made two requests to the users root, on the Apache one it made one request to the current directory.

[expert-geeks]

same issue nc 17

[danxuliu]

If I am not mistaken the problem comes from location.hash = "" and the fact that some browsers (like Firefox) trigger onpopstate and some browsers (like Chromium) do not (you can try it here).

The Files app listens to popstate events and triggers urlChanged events, which cause the file list to change to the new directory. When the RichDocuments viewer is closed it first clears the state (the ?dir=/XXX&fileid=YYY part) of the URL (note that this does not trigger an onpopstate event) and then sets location.hash = "". In Chromium no popstate event is triggered, so everything works as expected. But in Firefox this triggers a popstate event, and as the state was cleared the URL now refers to the root folder and the file list changes to it.

[juliushaertl]

Thanks a lot @danxuliu for digging into that. The strange thing is that i still don't see the behaviour with the latest FF, but i could reproduce it with ESR indeed. Not sure what is wrong there. However removing fixes the issue and I cannot see a reason why this would still be needed, even from the original introducing commit d106de7

[xtrasimplicity]

Thanks for releasing this as part of v3.4.5, @juliushaertl!

[tk7936]

just tested the update, all works again! Thanks to everyone!

[manu-p]

Thanks very much to all of you involved in this issue resolution!