Open falkecarlsen opened 5 years ago
Reproducible under Win10 on Firefox 66.0.4 64-bit as well.
And the list is not scrollable when cropped? I assume this has to do with the old problem from #26, where the fix was to scroll to the top of the main container. I thought I'd fixed this behavior by adding a padding to the file container though. I'll take a look and see what can be done.
No, the list is scrollable at all times. It seems that the file-tree toolbar is only 32px high, and the main toolbar is 39px high. Each item in the list is 32.8px high, and as the first picture shows, the view is cropped more than a single item's height. So I believe the issues does lie with the main toolbar.
Is the issue not reproducible for you?
I'm able to see all items in the list, with sources.bib
being the last file. The file is slightly cropped, but nothing that hides an entire element.
After triggering the scroll-to-top fix, i get a larger gap at the bottom:
... but still nothing that hides a file.
Hmm. Could it be browser-dependent?
Another idea could be that the structure of the project triggers the issue. Try opening an AAU-report template which has large directories and a single tex-file in root.
With the AAU report template i can get it to cover the file slightly, but nothing that hides an entire file.
Upon loading an Overleaf-project, the file-tree list is cropped. See picture of default AAU project-report structure - I'd expect
master.tex
at the bottom. Note that thepreamble.tex
button is slightly cropped as well.Upon fullscreening the browser-window, the view resizes correctly and persists when exiting full-screen viewing:
It seems that the height of toolbar is exactly the amount of crop that is applied and visually it seems to happen when the toolbar loads.
This is observed on Firefox 66.0.5-1 and back, under i3 and X11, if this is platform-dependent.