Version 3.0.0 on Nextcloud 28 prevents the file listing from loading completely. Lazy loading while/after scrolling broken

[ernolf]

If the README.md app is activated and a long file/folder list is displayed (in files list view), the entire file list will not be loaded. The folders and files that are outside of the focus are no longer loaded "lazy" as usual.

---

ernolf

[mamatt]

This should not happen, but ...the new dynamic height of the filetable is a nightmare to handle ... I've had tiple checked that ... but I certainly miss a case.

Can you provide more precises informations and a screenshot when it happen ?

[ernolf]

This is the behaviour without README.md activated:

https://github.com/mamatt/files_readmemd/assets/39901936/b552d160-9410-47f8-b91a-8f8c62f2a897

While this is the behaviour with README.md activated:

https://github.com/mamatt/files_readmemd/assets/39901936/4d527447-71cd-4004-9808-4d8629abb8f3

Only the first visible and cached files are loaded, the virtual file list as basicaly handled here: https://github.com/nextcloud/server/blob/master/apps/files/src/components/VirtualList.vue does not work.

---

the new dynamic height of the filetable is a nightmare to handle

Yes. I know. I had my rendezvous with this feature by tinkering around with the UI https://help.nextcloud.com/t/custom-css-to-enable-ultra-compact-list-view-in-files-nextcloud-27-and-28/174327/11?u=ernolf

My due respect for what you have reached so far :+1:

---

ernolf

[mamatt]

yes I have also reach the virtual Listview definition and the infamous calculated content height, which is exactly what css is supposed to do automatically. :/

I'll check in detail your last link and try to apply your solution. 👍

[jkraffthha]

Also affects grid view if there is enough item. Using the browser zoom out function allow to view more files so probably linked to height detection...

[mamatt]

@jkraffthha good point ! To be totally honest, I never use the grid view so I miss to check this kind of view ! For now I haven't found yet a proper way to solve this issue.

One solution could be to also dynamicly comput the top position of the footer, but from my point of view this is a totaly ugly solution !

[jkraffthha]

I'm also wondering how and why it affects folders that don't contains any .md files. I would have thought that those wouldn't be affected in any way by the app.

[Franselbaer]

You can see more of the listing, if you zoom in and out with command + or command - (STRG or CTRL on Windows). Same error with Chrome or Safari or other browsers.

[michel-thomas]

I confirm the bug with Nextcloud 29.0.3

@connor-lucas found out it comes from CSS -> https://github.com/nextcloud/server/issues/46470#issuecomment-2229062055

[blitzdesigner]

I can also confirm this bug with NC 28.07

[mamatt]

I'm out of office until august 12.

I'll dig more deeply when I'll be back.

[mamatt]

I'm also wondering how and why it affects folders that don't contains any .md files. I would have thought that those wouldn't be affected in any way by the app.

I've found the problems for this one, the bug won't affect folder without footermd. however I'll still working on the main problem aka the infamous lazy loading filetable !

[mamatt]

I'm also wondering how and why it affects folders that don't contains any .md files. I would have thought that those wouldn't be affected in any way by the app.

I've found the problems for this one, the bug won't affect folder without footermd. however I'll still working on the main problem aka the infamous lazy loading filetable !

fix by #174

[mamatt]

I've pushed a pre-release https://github.com/mamatt/files_readmemd/releases/tag/V3.0.1

Can you confirm that the CSS is not applied when there is no footer ?

Unfortunately please note that the main issue is still un solved :'(

[julpec]

When do you plan to roll out this update? At the moment, it's very difficult for us to work because we can't see all the files. Moreover, the bug affects any directory, even if it has neither header.md nor footer.md present. As soon as I disable the app, everything returns to normal. Thank you for this application, which is very useful for novice organizations as it gives users better guidance.

[nooblag]

Thank you for great software. Just confirming this issue for NC 29.0.7 too. I get the same thing as in https://github.com/mamatt/files_readmemd/issues/159#issuecomment-2200483054

[khassad]

Hi there, I chime in my thanks for those working on this great add-on and my support to solve this issue that plagues us also. All dirs, with or without .md, are affected and removing all files prefix in the module params does not help either.

Only workaround is to disable this module 😦 .

NextCloud 28.0.10

It's a bit ankward to test pre-release software on our production server.

[indigoxela]

I tested with Nextcloud Hub 8 (29.0.7).

Starting with Readme.md V3.0.0 on a test site. Verifying the problem with truncated display of long directories, regardless whether there's a readme on that page or not.

Then I (manually) updated to Readme.md V3.0.1, ran update routine, visited the same long directory again to check the display.

I can confirm, that 3.0.1 fixes the problem - all files are displayed properly again, great work. :+1:

[ernolf]

Can you confirm that the CSS is not applied when there is no footer ?

Yes, it works for me now.

Only issue now, is that it works only on folders when opened from the normal fileview (url: apps/files/files/...). but not when the folders are opened from the favorites view in the sidebar (url: apps/files/favorites/...).

Here the diff to fix that:

diff --git a/src/main.js b/src/main.js
index 08129d7..6122adf 100644
--- a/src/main.js
+++ b/src/main.js
@@ -40,7 +40,7 @@ document.addEventListener('DOMContentLoaded', () => {
                order: 100,

                enabled(folder, view) {
-                       return view.id === 'files' || view.id === 'files.public'
+                       return view.id === 'files' || view.id === 'files.public' || view.id === 'favorites'
                },

                async render(el, folder, view) {

---

ernolf

[mamatt]

I'll publish a 3.0.2 release quite similar to 3.0.1 but with a few dependencies update and @ernolf fixe for favoris. sould be publish this evening.

one again this doesn't solve the main issue with lazy loading

[mamatt]

3.0.2 has been published

[julpec]

Thank you so much !!! \o/

[ernolf]

one again this doesn't solve the main issue with lazy loading

Here the diff to fix that too:

diff --git a/src/main.js b/src/main.js
index 6122adf..36481d3 100644
--- a/src/main.js
+++ b/src/main.js
@@ -58,7 +58,7 @@ document.addEventListener('DOMContentLoaded', () => {

                        if (!document.querySelector('.footermd')) {
                                footerElement = document.createElement('div')
-                               document.querySelector('.files-list').after(footerElement)
+                               document.querySelector('.files-list').appendChild(footerElement)
                        } else {
                                footerElement = document.querySelector('.footermd')

---

Bonne chance, ernolf

[mamatt]

Unfortunatly I've tried the append approch, but this is not working either.

I'll try to spend more time on this in the next weeks

[ernolf]

but this is not working either.

Strange! For me it works perfectly. Are you sure that its not because of browser cache? Did you set debug mode to not cache js?

Or do you even mean a complete different issue?