File manager does not expand to fill the available window height

[nekohayo]

Tested with VirtualMin 7.7 on Firefox 115, the file manager GUI does not span the whole height of the window, there is a ton of wasted gray space below it:

It would be beneficial for it to expand to fill the available vertical space, that way you can fit a longer directory tree sidebar without scrolling, and fit more files in the listview without scrolling, too.

[iliajie]

Hello,

Currently, the file tree is in sync with the right panel, while the right panel does stretch to the full height if there is enough of files in the directory, i.e. /usr/bin.

Also, your current viewport is unrealistic, everything is barely visible.

[nekohayo]

Currently, the file tree is in sync with the right panel, while the right panel does stretch to the full height if there is enough of files in the directory, i.e. /usr/bin.

Ah, I see. I think it would still make sense to use the full available height (it's not like you're putting anything below the file manager anyway) at all times, even if the currently viewed folder does not have that many files. At least that way you reduce the amount of scrolling in the treeview sidebar, and you avoid the UI resizing up and down all the time depending on which folder you're browsing. Whatsmore, that resizing up and down is moving the position of the clickable pagination buttons, this is quite jarring and I would really not recommend doing that with a GUI's toolbar.

By the way, in large directories, I would personally expect scrolling whenever possible rather than pagination, unless we're talking over 1000 items in the view... pagination buttons are generally unpleasant to use, lots of clicks and you need to position the mouse cursor accurately, vs just using the mousewheel without needing to look (nor target a tiny area). I could file a separate ticket about that if you'd like to entertain the idea.

Also, your current viewport is unrealistic, everything is barely visible.

Unfortunately, it is very real 😉 :

[nekohayo]

One of my friends' 4x 42" vertical monitors setup is also quite realistic with a large enough desk ;)

[iliajie]

Jebus! 😆 I think you should Ctrl - + to zoom in a little bit.

Alright, I will add your suggestion to the todo as a feature request.

[SEJeff]

Can confirm, am said friend with silly 4 x 30” monitor vertical setup. You can tail ALL THE LOGS!

[nekohayo]

I also see now that the File Manager's global height is currently set based on a fixed number of items, so if you tell it to show 500 items per page and those items can't fit on screen... it scrolls the whole file manager UI including the toolbars, and the file manager's sidebar and file manager's content pane (instead of scrolling only their contents, i.e. the sidebar's folders list or the content pane's files list).

It would be technically easier (and also functionally nicer, from my user's point of view) for the global filemanager's height to match the browser viewport height, and for the inside of the two views (i.e. the sidebar's folders tree, and the content pane's files list) to be the parts that are scrollable, instead. That way, you won't have any problems scaling to any screen height, and you won't have the whole UI (including toolbars) unexpectedly shifting up and down like it does now.

[iliajie]

It would be technically easier (and also functionally nicer, from my user's point of view) for the global filemanager's height to match the browser viewport height,

This is already what must be happening by default, when File Manager Preferences page has Default number of items per page set to Automatic.

https://github.com/virtualmin/virtualmin-gpl/assets/4426533/45a4d987-e0d3-4999-bc5f-bb1bdc85722b

[nekohayo]

Well yes and no :) because the "Default" setting does content pagination instead of scrolling... but you are correct that it generally prevents the GUI exceeding the height of the viewport (while unfortunately not filling it if the number of files is insufficient, as originally reported above). Though here in my case, on a landscape display, it does slightly scroll the whole GUI up and down even when "Default number of items per page" is set to "Auto":

2023-09-24 webmin file manager global viewport scrolling.webm

In my comment above today, what I had additionally noticed (with the non-default "Default number of items per page" setting) is that when the number of content items exceeds the height capacity of the current implementation to fit in the browser's viewport, then the whole GUI scrolls even more noticeably.

So my observation today is still correct: for contents, it scrolls the whole GUI intsead of scrolling the content pane's files list. Sorry that I mistakenly thought the sidebar's folders tree was also affected by the exact same issue though.

Therefore my overall recommendation remains this combination of related things:

1. Make the contents pane's file list scrollable (instead of the whole GUI);
2. Make the whole GUI always fill the viewport's height, particularly in "auto" mode;
3. Optional, but recommended:
   While we're at it… I suggest getting rid of the "Default number of items per page" (and the "Show [number] items" widget that shows up in the toolbar when "Default number of items per page is not "Auto") setting, at this point? It's complexifying everything and causing more issues than it seems to solve.
   After all, for performance* (pretty much the only reason I can think of for pagination) you already have the "Maximum number of items in directory without using server pagination" setting, that you can default to 500 or 1000 I guess. Then, auto-pagination or not, the contents pane's files list should be scrollable.

In terms of UX, it does not make that much sense to have the user click a bunch of times on page numbers by default (and having three settings instead of one), instead of letting them use the scroll wheel (or touchpad scroll) like in other file managers.

---

*: Even the performance implications are questionable below 1000 files, I think. Out of curiosity, I did a simple test here, doing a large folder listing with ls -lha, and it is pretty much instantaneous on any machine I've tried. For example:

time ls -lha /usr/bin on my laptop with an SSD and ext4 filesystem, where that folder contains 2350 items:

real    0m0.067s
user    0m0.023s
sys 0m0.034s

The same time ls -lha /usr/bin command on my Debian 11 virtualmin home server with a HDD (not SSD!) and a 15-years-old "Pentium D" CPU, with 1667 files in /usr/bin:

real    0m0.097s
user    0m0.012s
sys 0m0.062s

So even my old machine without a SSD takes less than a tenth of a second to display the details of over 1500 files with ls... so I suspect that scrolling instead of paginating "to the screen height" (which can only fit a maybe 30 to 70 items or so, typically) would probably have an insignificant performance impact.

If you are worried about performance overhead from virtualmin's file manager compared to ls, there would still be the "Maximum number of items in directory without using server pagination" setting; I just don't see the point of having essentially the same option twice (or even thrice, considering how the file manager also presents a "Show [100] items" thing in the toolbar for some reason).

[iliajie]

it does slightly scroll the whole GUI up and down even when "Default number of items per page" is set to "Auto"

This is 100% expected. I don't understand why you expect page to be scrolled in this case scenario, i.e. with "Auto" mode enabled.

• Make the contents pane's file list scrollable (instead of the whole GUI);

That is less likely, making pagination jump forward and back on scrolling would be an interesting feature (maybe). Although, you can already use Alt + -> and Alt + <- hotkeys to do it.

While we're at it… why not get rid of the "Default number of items per page" (and the "Show [number] items" widget that shows up in the toolbar when "Default number of items per page is not "Auto") setting,

I simply don't understand what you mean. Please be concise! We do have it all that you're asking for, if "Auto" mode is disabled, e.g.:

https://github.com/virtualmin/virtualmin-gpl/assets/4426533/7a2f57f7-43a5-4057-bb3a-fd48a106a259

In terms of UX, it does not make that much sense to have the user click a bunch of times on page numbers by default (and having three settings instead of one), instead of letting them use the scroll wheel (or touchpad scroll) like in other file managers.

What other file managers? Do you mean HTML (web) file managers?

Even the performance implications are questionable below 1000 files, I think. Out of curiosity, I did a simple test here, doing a large folder listing with ls -lha, and it is pretty much instantaneous on any machine I've tried.

You cannot compare ls output in the terminal and and in File Manager. Putting to much HTML on the page is bad for performance. File Manager itself can list super fast a directory containing million of files, but with server pagination enabled.

I just don't see the point of having essentially the same option twice (or even thrice, considering how the file manager also presents a "Show [100] items" thing in the toolbar for some reason).

Table pagination (read JavaScript pagination) and server pagination are two different features.

---

I would like to ask you something. We really appreciate your reports and suggestions, they mean a lot, but please provide them in a more concise manner.

[iliajie]

That is less likely, making pagination jump forward and back on scrolling would be an interesting feature (maybe). Although, you can already use Alt + -> and Alt + <- hotkeys to do it.

Sorry, not Alt, just arrows left and right.

[nekohayo]

Basically, the simplest test cases here (with an example folder containing ~1400 items, shown on a maximized browser window on a 1600x900 display) are:

• If set to Auto, on my screen it will show only 15 to 21 items, spread across 75+ pages, instead of showing a scrollable content view ; Auto should mean automatic and scrollable as long as it doesn't destroy performance, so only paginate in extreme cases if reaching "Maximum number of items in directory without using server pagination" .
  Paginating across 75+ pages of only 15-30 items or so is counterproductive for the user.
• If set to something other than Auto (ex: 500 items per page) for testing purposes, then the whole GUI exceeds the viewport height and it scrolls the entire file manager GUI instead of scrolling only the contents. But anyway, I shouldn't even have to use something other than "Auto", in the first place.

My point is that these two related issues are suboptimal. My 2 (or 3) recommendations in the comment above would be a way to solve this UX problem, and ideally it also provides a way to reduce your number of pagination-controlling variables to 1 instead of 3.

Does this summary help?

[nekohayo]

Here's an annotated screenshot showing what I mean, for Auto mode:

[iliajie]

• Auto should mean automatic and scrollable as long as it doesn't destroy performance, so only paginate in extreme cases if reaching "Maximum number of items in directory without using server pagination" .

No, "Auto" means put the page into the viewport by automatically choosing the number for pagination.

Paginating across 75+ pages of only 15-30 items or so is counterproductive for the user.

So, why not go and change it File Manager preferences page?

If set to something other than Auto (ex: 500 items per page) for testing purposes, then the whole GUI exceeds the viewport height and it scrolls the entire file manager GUI instead of scrolling only the contents.

I understand that this could be potentially an improvement. However, you already can easily make desired changes in File Manager preferences page, however controls will be scrolled as well.

Also, you say "Auto mode shouldn't paginate unless hitting performance limit" -- well there is no straight forward way to tell when the page hits "performance limits". This is the reason why it's configurable in preferences.

The only option I may consider adding is scrolling file manager table ..

Although, I don't understand exactly why would you want anything else but defaults. Besides, if server pagination is disabled and JavaScript pagination is active, you can simply start typing for a file name and in no time get filtered results for the files you're looking for.

[nekohayo]

No, "Auto" means put the page into the viewport by automatically choosing the number for pagination.

I understand that's "what it does" currently... But I think it is not what it should do in terms of UX, ideally.
It would be much nicer to automatically show a reasonable amount of files by default (hundreds, not dozens) that can be scrolled "within the view", not scrolling the whole GUI.

Unless your goal is really to not ever have scrolling by default, but I don't know why you'd want that in terms of UX.

So, why not go and change it File Manager preferences page?

I know we can change the setting, but then:

• Ideally, users shouldn't have to :)
• You'd hit the 2nd part of my bug again, the "whole GUI scrolls" problem (as you say: "controls will be scrolled as well"). Fixing that part of the problem is going to make things better in any case, of course.

---

there is no straight forward way to tell when the page hits "performance limits". This is the reason why it's configurable in preferences.

Well, I've been trying to imagine any scenario where displaying 500 to 1000 files would be a problem, on any system, and am unable to find one... do you have an example of this being a problem in practice, where it was only feasible to show 15-30 files at a time? (remember that even if you don't show them in directly in the view, you also have to analyze the folder's files to figure out the number of pages, or to offer sorting and searching features... so are you really actually saving that much by hiding stuff into pages, unless it's tens of thousands or millions of files?).

Performance thoughts:

• On the server side: what VPS or Dedicated server out there in 2023 is only capable of returning the listing of 15-30 files a time and cannot show at least 250, 500, or 1000 items in less than half a second?
  My 15-years-old potato machine can do it, and even a RaspberryPi 4 is more powerful than that machine...
• On the client / HTML side: any modern web browser can render any ultra complex page in less than 300 miliseconds nowadays (including Chrome, Firefox, Safari) so I don't think its going to be a client-side performance problem either (it might have been true before 2018 and before 2008, but browsers are much faster to render anything you can throw at them nowadays).

Tens of thousands, or millions of files? Okay yeah, pagination probably helps with performance in that case.
Less than a thousand? I'm not sure it's actually needed for such a number and below...

---

What other file managers? Do you mean HTML (web) file managers?

As far as I can tell, cPanel's file manager doesn't do pagination and still responds instantly, while cPanel is usually running in worse conditions, controlling horribly over-loaded shared hosting servers ;)

Another example: WordPress' "Media Library" (on my personal blog) file browser tool is able to show me 999 items (including thumbnail, filename, date, filesize, and a bunch of other metadata) on a single page (in the admin GUI) in less than 1.5 seconds (probably faster than that, but I'm too slow to press the Stop button on my stopwatch) if I request it.

And of course, desktop file managers (on any OS) never do pagination either. Nautilus 45 or Thunar, for example, are able to show details for a couple of thousands of files in /usr/bin in a small fraction of a second... but yes I know, desktop file managers are probably an unfair comparison, and so cPanel (and WordPress) is probably a closer comparison 😉

[iliajie]

Jeff, did you manage to find the solution here using the File Manager configuration page, or is there still something missing?