fix(files): correct params on Go back link

[ShGKme]

Summary

Before, going back results an invalid URL. Updating the page results in infinity loop.

(Video with sound)

Before.mp4

This issue fixes the link. But probably we should also fix such an invalid link handling.

After-1.mp4

Also works on root.

After-2.mp4

TODO

• Remove aria-label - it is not correct to have aria-label different from a button text and not needed when there is a text
• Set fileid on "Go back"

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[JuliaKirschenheuter]

works, great!

[skjnldsv]

Suggested change

	{{ t('files', 'Go back') }}
	{{ t('files', 'Go to the parent folder') }}

[skjnldsv]

You should not need to provide the fileid.
Maybe making sure we just keep the view?

Suggested change

	const fileid = this.pathsStore.getPath(this.currentView?.id, dir)?.toString()
	// @ts-expect-error Route expect params to be string, but we need to explicitly set undefined when there is no fileid
	return { ...this.$route, params: { fileid }, query: { dir } }
	return { name: this.$route.name, params: { view: this.$route.params?.view || 'files' }, query: { dir } }

[ShGKme]

If I understand our files routing correctly, we always have fileid in the path, except root.

For example, if I open /Foo/Bar and Bar directory has fileid=700, then the current route is:

• In Files: /apps/files/files/700?dir=/Foo/Bar
• In favorites: /apps/files/favorites/700?dir=/Foo/Bar

Let's say, I'm in the root, then I'm going to Baz and back to Bar.

1. /apps/files/files?dir=/
2. /apps/files/files/699?dir=/Foo
3. /apps/files/files/700?dir=/Foo/Bar
4. /apps/files/files/701?dir=/Foo/Bar/Baz

From 4 shouldn't I return to 3 /apps/files/files/700?dir=/Foo/Bar?
Why /apps/files/files/?dir=/Foo/Bar?

If going back should be without fileid, does it mean that while going through directories forward and though breadcrumb there should also be no fileid?

1. /apps/files/files?dir=/
2. /apps/files/files?dir=/Foo
3. /apps/files/files?dir=/Foo/Bar
4. /apps/files/files?dir=/Foo/Bar/Baz

[skjnldsv]

we always have fileid in the path

no, having fileid in the path is optional, we don't rely on it to open folders or browse.
We only rely on it to scroll to a specific file in the current opened folder or trigger a file action on load

[ShGKme]

Does it mean that links to folders in the files list should not contain fileid at all?
Because there is no such a file in the folder, nothing to scroll to.

For example, if /Foo folder has fileid=700, then path /apps/files/files/700?dir=/Foo doesn't make sense — there is no "700" in the /Foo, only in parent /.

[skjnldsv]

You can have it or you can't.
It will have no effect on the loading of the folder.

the fileid, like in older versions, is only used within the Files app to work with a file within a folder (like open the sidebar, etc etc)

[skjnldsv]

1. Just in the file list when we go to the next folder
2. In the breadcrumbs
3. In the "Go back" link

1. Yes
2. Yes
3. aaaaand yes/no, it's good to have it but it's optional

We try to keep the current fileid for this specific reason: #40515

[ShGKme]

1. Yes
2. Yes

will trigger the sidebar action for the file id

Does it mean that opening any folder is supposed to also open a sidebar after it?

If it is not, we have a inconsistent here:

• Being on a page /:fileid doesn't open a sidebar
• Opening a link with /:fileid opens a sidebar
• => A fact of reloading a page opens a sidebar o_O

[ShGKme]

Probably, there should be a query param for sidebar, like ?details, similar to openfile?

[skjnldsv]

No please 🙈
Let's not complicate URLs.

Being on a page /:fileid doesn't open a sidebar
Opening a link with /:fileid opens a sidebar
=> A fact of reloading a page opens a sidebar o_O

That's not a inconsistency, this is the feature. It's been long discussed and implemented by the design team.
On load, if you provide a fileid for a FILE, we open the sidebar (if screen size allows)

[skjnldsv]

Also, please, let's not dive into this and reconsider 6 years of feature requests, this is not what this issue is about at all.
You have no idea the amount of use cases the Files app supports and I had to match up.

[ShGKme]

Closed in flavor of #43174