Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: ONLYOFFICE Document Server: document is not opened in the ONLYOFFICE editor by default #49049

Open
4 of 8 tasks
alexonlyoffice opened this issue Nov 2, 2024 · 7 comments
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 30-feedback bug

Comments

@alexonlyoffice
Copy link

alexonlyoffice commented Nov 2, 2024

⚠️ This issue respects the following points: ⚠️

Bug description

Newly created file is not opened in the ONLYOFFICE editor by default, if the previously opened file was closed by Open file location button.

Checked on Nextcloud Hub 9 (30.0.1), ONLYOFFICE Connector 9.5.0, DS 8.2.0. Here is the video showing the case

2024-10-24+13-41-04.mp4

This is how document creation is implemented in integration:

We implemented registerTemplateFileCreator.

On the client we have document creation registration registerFileAction.

During the first document creation exec method is fired and successful document opening follows. The issue is that after quitting the editor and repeated creating of the document in the same tab without page refreshing the exec method is not invoked.

Steps to reproduce

  1. Make sure Open file in the same tab checkbox is marked in the connector settings;
  2. Create a document in All files section -> editor will open;
  3. Leave the document by clicking on the Open file location button on the editor toolbar;
  4. Create a new document -> editor will not be opened, document appears in the file manager.

Expected behavior

Newly created file is opened in the ONLYOFFICE editor by default

Nextcloud Server version

30

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

@juliusknorr, could you please take a look?

@alexonlyoffice alexonlyoffice added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Nov 2, 2024
@solracsf solracsf changed the title [Bug]: ONLYOFFICE Document Server+Nextcloud. Document is not opened in the ONLYOFFICE editor by default [Bug]: ONLYOFFICE Document Server: document is not opened in the ONLYOFFICE editor by default Nov 7, 2024
@blizzz
Copy link
Member

blizzz commented Nov 12, 2024

@artonge @susnux isn't it similar to what we tackled with nextcloud/viewer#2368 and #47016?

@juliusknorr
Copy link
Member

juliusknorr commented Nov 13, 2024

I've been reproducing this and noticed that it seems to be caused by the use of window.history.pushState which likely causes side effects with the vue router that is used in files now. It seems that after the use of pushState when opening or closing a file the next call to open the new file with OCP.Files.Router.goToRoute is no longer doing anything.

@susnux @skjnldsv Is that a known thing for the vue/files router?

A quick attempt to fix this is the following patch for the onlyoffice app would be this:

diff --git a/src/main.js b/src/main.js
index e04170c..f32f13e 100644
--- a/src/main.js
+++ b/src/main.js
@@ -179,7 +179,11 @@ import NewPdfSvg from '!!raw-loader!../img/new-pdf.svg';
                        $(OCA.Onlyoffice.frameSelector).css('top', scrollTop)

                        OCA.Onlyoffice.folderUrl = location.href
-                       window.history.pushState(null, null, url)
+                       window.OCP.Files.Router.goToRoute(
+                               null, // use default route
+                               OCP.Files.Router.params,
+                               { ...OCP.Files.Router.query, openfile: 'true' },
+                       )
                }
        }

@@ -193,7 +197,11 @@ import NewPdfSvg from '!!raw-loader!../img/new-pdf.svg';
                let url = OCA.Onlyoffice.folderUrl
                url = url.replace(/&?openfile=true/, '')
                if (url) {
-                       window.history.pushState(null, null, url)
+                       window.OCP.Files.Router.goToRoute(
+                               null, // use default route
+                               OCP.Files.Router.params,
+                               { ...OCP.Files.Router.query, openfile: 'false' },
+                       )
                        OCA.Onlyoffice.folderUrl = null
                }
        }

@susnux
Copy link
Contributor

susnux commented Nov 13, 2024

Is that a known thing for the vue/files router

I remember something like this in the legacy Vue2 router but can not find any reference anymore..
This is known, so just do not use the history manually:

vuejs/router#956

@susnux susnux closed this as completed Nov 13, 2024
@susnux susnux reopened this Nov 13, 2024
@alexonlyoffice
Copy link
Author

thanks, we are checking the provided workaround.

@alexonlyoffice
Copy link
Author

I can confirm that the suggested solution works for us. Thank you for you help!

@alexonlyoffice
Copy link
Author

Hello, I have to re-open the issue as the suggested solution does not work for the folders shared via the external links, there is an error in browser dev tools like this:

window.OCP.Files is undefined

@alexonlyoffice alexonlyoffice reopened this Dec 2, 2024
@juliusknorr
Copy link
Member

Looks like OCP.Files.Router is only available with the files to vue migration in public shares starting with the upcoming 31 release.

@alexonlyoffice I'm not sure if your integration uses the viewer app on public share links or if you can give it a try with a fallback on the old approach.

In case of viewer there is a known issue with history handling (nextcloud/viewer#2577) but opening of new files should not depend on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 30-feedback bug
Projects
None yet
Development

No branches or pull requests

5 participants