WebDAV is fetched twice on initial page load

[juliusknorr]

Steps to reproduce

• Load the files app through /apps/files
• Observe the network requests

Current behaviour

The PROPFIND on the root directory is sent twice

Actual behaviour

Only one request should be done

Additional context

Reproducible on 29.0.2 and latest master

@nextcloud/server-frontend

Related PRs

• fix: Remove duplicate propfind call #50109
• fix(files): reduce number of fetch contents on load #47102
• perf(files_sharing): do not emit second propfind for account filter #51937

[juliusknorr]

Same is actually the case when going to the recents view and reloading the page

[skjnldsv]

server/apps/files/src/views/FilesList.vue

Lines 480 to 481 in 1d7893d

	// reload on settings change
	this.unsubscribeStoreCallback = this.userConfigStore.$subscribe(() => this.fetchContent(), { deep: true })

Coming from here @susnux

[susnux]

Probably it triggers a settings change directly on init?
Or the view is loaded before the settings?

[skjnldsv]

Or the view is loaded before the settings?

probably that

[juliusknorr]

It seems things got worse, so maybe worth to schedule looking into this @sorbaugh

just noticed on my local instance it is doing 4 propfinds against the root on a page load, same on our prod.

[skjnldsv]

On it

[susnux]

I think the reason why it is increasing is that there is no other way for other apps to load the current content.

Meaning if you need the current content of the files app, you have to use view::getContent there is no way to get a cached version of the current content.
So if we do not want to introduce new API, we could just extend the current by adjusting View::getContents to have a parameter force = true (most secure backwards compatibility).

This would not need any adjustments of using apps, as the ViewData could stay as it is (so the View constructor call), but we just need to adjust the View class to cache the returned value for a given path and only call the ViewData::getContents when force is set.

[skjnldsv]

Yes and no, there are various issues:

1. the filter indeed gets their own contents
2. The Filelist monitors any userConfig store changes, so it gets triggered again on initial populating
3. The uploader fetch its own content on init too

I'll address 2 and 3 in a minute, still thinking about 1

Basically there was 2 content fetched, and #45708 added 2 more