I run Nextcloud 33.0.7.1 and have a folder containing roughly 26,500 entries. Browsing it was very slow, and I also encountered freezing and problems choosing a destination when moving folders.
I developed and locally deployed several repairs:
A folder-picker fix preventing older directory responses from replacing the currently selected destination.
Improvements to picker rendering and main Files loading/Retry behavior.
Reduced overhead when creating file objects.
Progressive listing: 96 rows initially, followed by batches of up to 256, so the folder becomes usable while the remaining entries load.
A small UI cleanup retaining the loading spinner without a prominent progress message.
It now feels much better in my ordinary use.
Synthetic testing preserved all 26,554 entries and showed substantially faster initial display. However, completing the entire listing took longer. Some memory growth and completion stalls remain, and unsupported modes still use the original full-list behavior.
These are local patches needing maintainer review, not an upstream-approved release. Development and automated testing were AI-assisted; my own confirmation is that browsing on my installation is noticeably more usable.
I’m preparing a sanitized package containing source patches, relevant tests, build instructions, benchmarks, limitations, and rollback information.
Would any maintainers or contributors be interested in reviewing the approach? I’d appreciate guidance on which changes should become separate contributions to the server, dialogs, or Files library repositories.
First, I have to admit, that I am no official dev of Nextcloud nor am I affiliated. Just moderator and community dev.
Generally, it is highly appreciated if you manage to not only report and grunt about issues but are able to actually solve them yourself. So, let’s look into this a bit closer.
The core devs typically do not visit the forum. It is not their main job description and they do not have the time to really follow. They use GitHub as the base for their work.
Having said this, opening a PR against the server is always the best chance to get such a thing fixed. Do it the next week as there is community week after the conference (in a bit more than a week) in Berlin. There are good chances that your PR is at least seen there.
From my own experience, smaller PRs are easier to handle and review. So, if there is a natural boundary in your patch that allows you to separate concerns, I (personally) would advice to separate. It is more work at first but the chances a re higher to get this done. Also, you might get feedback more directly.
You will have to conformant with all policies, so be prepared to rework it slightly if the build fails for some reason.
If you are unsure about certain aspects, you can open issues but these might keep unanswered for some time, I fear, just my personal experience.
Thanks for taking the time to explain this—that helps.
I’m preparing the picker fix as a small, separate contribution with its regression tests. It’s already tested and deployed on my installation; I’m now getting the existing changes organized for upstream review.
I’ll keep the larger Files and progressive-loading changes separate, follow the contribution and clearly document the testing limitations. I’m happy to make adjustments based on feedback.
Thanks also for the heads-up about community week!
Thanks again for the guidance. I separated the folder-picker race-condition repair and opened my first pull request:
This contribution focuses only on preventing older directory responses from replacing theодаря? Need no typo. Let’s write correct.
the most recently opened picker destination. It includes focused regression tests for delayed responses, cancellation, failed loads and destination confirmation.
I’ll keep the larger Files performance and progressive-loading changes separate.