-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vislib: Fix position calculation of ticks in non-horizontal axes #62309
Vislib: Fix position calculation of ticks in non-horizontal axes #62309
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
@markov00 down for a last round of |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wasn't immediately obvious to me what this change is about. Tested with the following scenarios:
- created vertical bar chart on sample data logs
- y-axis is sum of bytes
- x-axis date range on
@timstamp
field
Positioning of x-axis: - x-axis is bottom
- x-axis is left
- x-axis is right
All works as expected. Tested on Mac OS in Chrome 80.
Great for adding a functional test as well 👍 ✅
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Tested on Mac Chrome 80 with a vertical bar (date-range aggregation) rotating the chart and all labels are now shown correctly with or without the filter label configuration enabled
Fixes #21589
This PR fixes the hopefully last instance of the problem discovered here: #62004 (review):
Most of this was already cleaned up with this PR: #47563
But it didn't take one case into account:
If
Filter labels
is enabled, the very first label of the vertical axis is always filtered out, even if there is enough space.This happens because the calculation of the current tick position didn't correctly take the scale padding into account for vertical scales - it was always added even though it has to be subtracted in this case because vertical scales are inverted.
This PR includes a functional test for this specific case and fixes the existing one for the general case (it confused x and y axis).