Log view page is a little clunky and basic compard to the rest of the interface

[skyboy]

This only occurs with configuration errors or logging all requests, but the log's pre element makes navigating that page a little clunky; the best two ways, in my opinion, to make a smooth experience would be one of:

• Limit the maximum height of #preLogViewerBody to some limit <= 100vh keeping it constrained to the screen's bounds. Personally, I find 65-70vh works well (ignore the errors, they do make a nice demonstration for this effect however):
  
• Make either an element that is dedicated to scrolling the page back to the top, or make .log-list-pane position: sticky so it follows the page scroll, making cross-referencing multiple days of logs easier; a [top]-like option could also then be added instead of a separate UI element

---

I can further see the log-list becoming problematic, as it appears - though I do not yet have enough logs to confirm - that it will overflow the screen height as well: grouping logs into date-ranges wouldn't be amiss as a feature here and just opening 'folders' to get at logs other than the latest batch would help control this, particularly on servers hat wind up running for years on end without being cleared manually or automatically; I would suggest something along the lines of year > month > "week" (quarter or half months in practice) > day
If desired, I can sketch out a demo with some code for the UI template, though pagination may be a simpler and better option - one that is additionally already implemented elsewhere in the interface code and would be much faster to add even in this more constrained space.

[skyboy]

• Make either an element that is dedicated to scrolling the page back to the top, or make .log-list-pane position: sticky so it follows the page scroll, making cross-referencing multiple days of logs easier; a [top]-like option could also then be added instead of a separate UI element

It took a little longer to sort out a demo of that because there's some css fixes needed to make it scroll properly:

.log-list-pane {
				position: sticky;
				top: 15px;
}

.log-viewer-pane {
				/* float: right; */
}

#divLogViewer {
				/* display: block; */
				display: inline-block;
				padding-left: 15px;
}

[ShreyasZare]

Thanks for the feedback. This suggestion however makes it more difficult to navigate. Now it adds two scroll bars, one on the web page and one for the log viewer. So, using simple navigation keys (like space bar, page up/down, home, end, etc.) on the webpage becomes difficult. Right now, you can navigate to the latest log entry just by pressing END key and get back to the top using HOME key. I am thus not sure how this suggested change is improving user experience.

[skyboy]

I tend to focus on mouse-oriented designs, as most people are unaware of keyboard navigation (albeit, this is a DNS server so the users are significantly more tech-savvy):

• The first suggestion for limiting the maximum height can also be reduced in height to bring the footer on screen and eliminate the full window scroll bar

in this much-reduced state, a button to expand the pre or one of its parents to be fullscreen via JS's Element.requestFullscreen() would make it more navigable without downloading the log outright.

There is additionally a consideration as to whether or not footers are desirable in modern designs, as their presence creates these kinds of issues and rule out the possibility of adding infinite-scrolling pages; a feature that could see use on the zones tab, where new pages are automatically loaded and appended. Infinite-scroll is more of a moon-shot consideration, though and not a direct recommendation - proper pagination still has its place.

• The second suggestion retains only the single window scroll bar, but keeps the panel for navigating between log files visible, the addition of an element for navigating back to the top with a mouse click would further unify it and align it with many modern websites usage of a dedicated - often position: fixed - element that fulfills this purpose however with a navigation element already on screen the 'return' element can simply be added to it instead of making it dedicated.

This styling can also be implemented in other ways than the quick css tweaks I included in #946 (comment), such as using display: grid and grid-template-columns which improves overall flexibility of design.

[ShreyasZare]

Thanks for the suggestions. The log view does need an upgrade since the current design limits the file to load max 2MB of data since loading more causes issues with web browsers. So, will plan something with it where it becomes possible to navigate the entire log file and also make it a bit mouse friendly.

[skyboy]

I had noticed that occasionally when viewing a file it would flicker out of existence if I scrolled down to the bottom sometimes, but when I shrank the max-height that stopped happening entirely so the solution may be the upgrade in its own right?

I suspect it's a node-length problem and splitting the text inside the pre up into separate elements with span every couple hundred lines will make it work as expected with minimal effort. Something along the lines of:

pre.innerHTML = log.split( /((?:[^\n]*\n){100})/g ).map( (v, i)=> v !== "" ? v : i === 0 ? "<span>" : "</span><span>" ).join('');

Which splits on every 100 line grouping with a capture group, reducing the match to an empty string and then adding the capture group as a separate element in the array after, then runs it through map to replace the 0th empty string with an opening span and all others with close-open spans; the final span is not closed, but the browser will do that automatically

Edit: After stewing on it a bit, just replacing \r?\n with <br> might also fix it, as no individual text node is ever that large then.

[ShreyasZare]

The log file can go in GBs so it wont be good to load it completely in the web browser. This needs to be some kind of pagination where only relevant section of the log file is displayed.

[skyboy]

Fair: It needs both in some capacity - having the text phase out of existence in some cases is as undesirable as waiting minutes to download and crash.

I'm just spitballing because I wouldn't be in the field if I didn't enjoy problem solving:

Without the footer or having the log scroll separately, an infinite-scroll solution could be applied here and you can just chunk it into <x> MB requests. When wrapped in a display: inline element this is super easy, further if newlines are replaced with html linebreaks then when a particular chunk is deemed to be 'too old' its text content can be deleted as chunk.childNodes.forEach(e=> e.nodeName==="#text" && e.remove()); and then marked as unloaded preserving its height and not affecting the scroll while unloading. An IntersectionObserver (or two? I'd need to put code to practice) with rootMargin: -<windowHeight>px 0px -<windowHeight>px 0px can handle the loading and unloading of chunks if the view is pre-populated with the correct number of elements based on the byte length of the log file being viewed; to prevent all chunks from being loaded simultaneously the empty elements will need to be size-adjusted which is pretty easy with a touch of css:

#text-chunk:empty::before {
	display: block;
	content: "";
	height: 1200px; /* or whatever is appropriate on average for the chunk size */
}

However, this solution is heavy on client processing in the spirit of keeping servers resource-light, and may or may not be applicable to the admin panel; the infinite-scroll approach also possibly clashes with other elements of the design.