Fix logs view

[selinanatschke-mms]

Description

Log view was already implemented but could not be used due to scrolling bugs.

Fixes

scrolling fixes:

• Logs View was very buggy: when user scrolls, scrolling wheel jumps or it gets stuck and causes flickering
• cause: most probably aurelia virtual.repeat cannot handle elements that do not have the same height => probably gets stuck between function calls (triggered by the position of the scrollingwheel) that load more content up or down
  (I experienced the same behavior when i tried to recreate dynamic scrolling by myself)
• fix: use bigger blocks to reload content dynamically so the scrolling wheel does not accidentally cross mark for reloading content in the opposite direction (=> more or less recreate aurelias virtual-repeat functionality)

search fixes:

• fixed search-jumping by using scrollIntoView() instead of calculating scroll distance
• instead of scrolling through all messages, now only the found message is loaded and the messages around
• added searching for stackTrace.messages (found results were highlighted but not considered when jumping through results)
• converted search results for loggerName (sometimes there were search results in the data model but the result was not displayed on the website because it was converted with a statusConverter)

general improvements:

• instead of scrolling whole page there is a scrolling window now (height dynamically according to https://getbootstrap.com/docs/5.0/layout/breakpoints/)
• search feedback: when searching a term there will appear a helper text that shows how many results there are and which one the user found => jumping by using the enter key

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Known Issues / Future Work

• scrollIntoView() uses ids to get elements => created long ids from log-line content to get individual id => consider to add id field to logMessage model

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[mreiche]

Did you test your changes with big log files, like 50 MiB of log entries for example? Because that's the reason, why UI virtualization exists.

instead of scrolling through all messages, now only the found message is loaded and the messages around

This sounds like filtering, not searching. These are different use-cases.

[selinanatschke-mms]

Did you test your changes with big log files, like 50 MiB of log entries for example? Because that's the reason, why UI virtualization exists.

The biggest files i tested had 13000 log lines. The goal was not to remove UI virtualization but to fix the lagging problem. Trying that i realized that removing the aurelia virtual-repeat also fixed the lagging but we wanted to reload content dynamically, that is why i implemented the dynamic reloading by myself

instead of scrolling through all messages, now only the found message is loaded and the messages around

This sounds like filtering, not searching. These are different use-cases.

What i meant by that is that by pressing enter you jump to the next search result. Therefore the window is not scrolling and reloading blocks until it finds the result, but instead it finds the result immediately and loads messages around the result.
This behavior avoids loading many many new blocks just to get to the one that contains the search result. When you got the result the dynamic scrolling in both directions (up and down) works the same way it did before, so there is no filter activated, all messages can be seen by scrolling even after searching.
The user does not see that not all messages are loaded in the DOM

But if you imply that filtering is used to only load messages in the DOM that are located around the search result, you are right.

[mreiche]

Did you test your changes with big log files, like 50 MiB of log entries for example? Because that's the reason, why UI virtualization exists.

The biggest files i tested had 13000 log lines. The goal was not to remove UI virtualization but to fix the lagging problem. Trying that i realized that removing the aurelia virtual-repeat also fixed the lagging but we wanted to reload content dynamically, that is why i implemented the dynamic reloading by myself

Please try with the complete log of the Integration test suite in DEBUG mode. Or ask @martingrossmann, because he had a big test suite with many logs that result in UI freezes in log view before introducing UI virtualization.

This sounds like filtering, not searching. These are different use-cases.

What i meant by that is that by pressing enter you jump to the next search result. Therefore the window is not scrolling and reloading blocks until it finds the result, but instead it finds the result immediately and loads messages around the result. This behavior avoids loading many many new blocks just to get to the one that contains the search result. When you got the result the dynamic scrolling in both directions (up and down) works the same way it did before, so there is no filter activated, all messages can be seen by scrolling even after searching. The user does not see that not all messages are loaded in the DOM

But if you imply that filtering is used to only load messages in the DOM that are located around the search result, you are right.

Just to make sure there is not misunderstanding: The previous approach was, to simulate searching of keywords through the log view by finding the next result, scrolling to and highlighting it. It should behave like searching through a document in the browser or a regular text editor. Not any line should be hidden (filtered) by the search.

[selinanatschke-mms]

Did you test your changes with big log files, like 50 MiB of log entries for example? Because that's the reason, why UI virtualization exists.

The biggest files i tested had 13000 log lines. The goal was not to remove UI virtualization but to fix the lagging problem. Trying that i realized that removing the aurelia virtual-repeat also fixed the lagging but we wanted to reload content dynamically, that is why i implemented the dynamic reloading by myself

Please try with the complete log of the Integration test suite in DEBUG mode. Or ask @martingrossmann, because he had a big test suite with many logs that result in UI freezes in log view before introducing UI virtualization.
Ok, I will try it

This sounds like filtering, not searching. These are different use-cases.

What i meant by that is that by pressing enter you jump to the next search result. Therefore the window is not scrolling and reloading blocks until it finds the result, but instead it finds the result immediately and loads messages around the result. This behavior avoids loading many many new blocks just to get to the one that contains the search result. When you got the result the dynamic scrolling in both directions (up and down) works the same way it did before, so there is no filter activated, all messages can be seen by scrolling even after searching. The user does not see that not all messages are loaded in the DOM
But if you imply that filtering is used to only load messages in the DOM that are located around the search result, you are right.

Just to make sure there is not misunderstanding: The previous approach was, to simulate searching of keywords through the log view by finding the next result, scrolling to and highlighting it. It should behave like searching through a document in the browser or a regular text editor. Not any line should be hidden (filtered) by the search.

Yes right. There is nothing hidden in terms of being unreachable. They are just not displayed in the DOM because they are outside of the viewport anyways. By searching we just jump to another part of the logmessage-"text"

I will record a video to clear all misunderstandings

[mreiche]

I will record a video to clear all misunderstandings

I think this is not necessary :) I believe that your colleagues have seen the result and accepting it.

[martingrossmann]

@mreiche Yes, we have tested the new implementation also with big excution files and a huge number of logs. The look-and-feel is the same. Except, scrolling is working.