[Logs UI] Fix initial accuracy of logs minimap click

[Zacqary]

Summary

Partial fix for #48614

Fixes the way the log minimap processes clicks. It was previously using a state value to calculate the top of the minimap element, but this state value only gets updated when the user drags the minimap. Therefore, it would return an inaccurate value and jump the user to the wrong time if the user clicked on the minimap before they dragged.

Now, the click handler will get the current DOM top of the minimap element rather than trying to pull it from state.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• [ ] This was checked for cross-browser compatibility, including a check against IE11
• [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• [ ] Documentation was added for features that require explanation or tutorials
• [ ] Unit or functional tests were updated or added to match the most common scenarios
• [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: db845a6

[afgomez]

I pulled the branch but it still jumps to the incorrect time :/ I'm using the shared 8.0.0 cluster to test.

I see in the description this is a partial fix. What parts would be missing? How can I help?

[Zacqary]

Okay so there's a second problem here: clicking on the minimap is also not sending a new timestamp to the request to fetch new logs, it's still using whatever the current target is. Changing the timestamp in the toolbar does successfully update this.

Not sure where this regression occurred but I'll keep digging.

[Zacqary]

The issue was stemming from the VerticalScrollPanel reporting the new timestamp and requesting to load additional entries as if the user had scrolled up or down. This was sending a second GraphQL request with the current timestamp instead of the new timestamp.

I made a change to cut down on reports unrelated to scroll events, and that seems to have fixed it.

Although it looks to me as if the scrolling requests aren't working. Both before and after my change, I tried scrolling to the edge of the logs and the Loading additional entries... message never actually yielded any additional entries. Might need to open another issue around that.

Anyway @afgomez as for this being a partial fix; the other part of the issue is a UX issue that would be more complicated to implement, and also has some unanswered questions around it. I just left a comment on the issue explaining further.

[afgomez]

Cool. Thanks for taking a look 👍

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d70f60c

[Zacqary]

@afgomez Any chance I can get a 👍 on this for review?

[afgomez]

Tested locally and it works 👍