[Bug]: Files are automatically opened when entering a folder

[muchachagrande]

[Bug]: Files are automatically opened when entering a folder

[muchachagrande]

There is an ?openfile=true property being sent in the URL, I can see it when reentering to the previous visited folder and it causes the previous opened file to be reopened. This happens with any type of file, PDF, DOC, TXT, JPG, etc.

[Syraxius]

I encountered the same bug as described below.

Environment:

• Snap Version: installed: 29.0.2snap1 (42890) 340MB -

Steps to Reproduce:

1. Open Folder in New Tab:

   • Action: Browse to a folder for the first time in a new tab.
   • Result: No issues.

2. Refresh Page:

   • Action: Refresh the page.
   • Result: No issues.

3. Open a File:

   • Action: Open a file.
   • Result: No issues. The URL appends with &openfile=true.

4. Close the File:

   • Action: Close the file.
   • Result: &openfile=true remains in the URL.

5. Refresh Page:

   • Action: Refresh the page.
   • Result: The file opens again, but &openfile=true disappears from the URL.

6. Close File Preview:

   • Action: Close the file preview.
   • Result: &openfile=true appears after the preview is closed (it disappears when the preview opens).

7. Navigate to Another Folder:

   • Action: Use breadcrumb to browse to another folder.
   • Result: &openfile=true disappears, but a "File not found" popup appears on the top right. It seems the system is still trying to open the same file.

8. Return to Original Folder:

   • Action: Browse back into the original folder.
   • Result: The file reopens, and &openfile=true appears briefly before disappearing.

9. Open Same File Again:

   • Action: Open the same file again.
   • Result: No issues. &openfile=true reappears.

10. Close the File:

    • Action: Close the file.
    • Result: No issues, &openfile=true disappears, which is the expected behavior.

11. Refresh Page Again:

    • Action: Refresh the page.
    • Result: The issue reoccurs from step 1.

Additional Observation:

• If a different file is opened in step 9 instead of the same file, the issue doesn't resolve and reverts to the behavior described in step 3.

Expected Behavior:
The &openfile=true parameter should be consistently removed from the URL after closing the file, and refreshing the page should not reopen the file unless explicitly instructed to do so.

[muchachagrande]

I also noticed the "File not found" message when navigating to another folder. May be related to the "&openfile=true" parameter on the URL.

[huntervcx]

Same behaviour, users need to get rid of the url parameter to stop opening the file or getting the "file not found" error message

Environment : Community Archive on a Debian 12, MariaDB, Php8.2

[jcharaoui]

I have had to deal with confused users because of this bug: opening certain folders shows a "File not found" error, while for others, it immediately loads a document in Nextcloud Office, or shows a photo, or starts playing a video...

The problem doesn't appear when loading Nextcloud in a private browsing window, which suggests the issue is related to browser cache and/or local storage.

[jcharaoui]

Possibly related to #43413

[Kharonus]

I have an addition to this bug.

When explicitly using an URL to a file with openfile=false, it even overwrites the url param and opens the file nevertheless.

Steps to reproduce:

• get any file id
• create a URL like: https://my.nextcloud.local/f/1001?openfile=false

Expected behavior:

• it shows the file in its location (folder)

Observed behavior:

• the URL changes to something like https://my.nextcloud.local/apps/files/files/1001?dir=/Folder&openfile=true very briefly
• file is opened in editor/detail view (for pictures)
• URL changes again to https://my.nextcloud.local/apps/files/files/1001?dir=/Folder

I can also verify this from @jcharaoui :

The problem doesn't appear when loading Nextcloud in a private browsing window, which suggests the issue is related to browser cache and/or local storage.

Doing this in a private window works as expected.

[pjft]

Related to #44635 as well. Coming here to report this.