Fix issue #4441 - y-axis labels partially hidden due to restrictive initial fitting.

[jcopperfield]

Fixes #4441 - y-axis labels partially hidden due to restrictive initial fitting.

The problem is caused by the layout service Step 4 being initially trying a chart area height of 50% of the canvas height. When in the initial case there's only enough space for integer ticks, then the y-axis will reserves only the width for integer tick labels. Later in Steps 5 & 6 this reserved space isn't allowed to increase, even when the allowed height is increased in this step.
A simple solution would be to increase the allowed height in the initial computation step to be maxChartAreaHeight instead of chartAreaHeight.

Issue v2.7

Proposed fix

[etimberg]

I think this is a safe change to make. The reason it was initialized to 50% height and width was to try and ensure that there was always area to show the chart on. Are the chartAreaHeight and chartAreaWidth variables still used? If not, we should remove them too.

I don't know that this will fix all the issues though. I think it's still possible to get the same case even when we start with the full area. A more generic solution would be to run fitting inside a loop until the sizes are stable but that has many risks including:

• not guaranteed to converge
• slower

[jcopperfield]

The variable chartAreaHeight is still used https://github.com/chartjs/Chart.js/blob/master/src/core/core.layoutService.js#L182

The bug is caused by initially fitting the ticks [1, 2, 3, 4, 5] in Step 4 and then in Steps 5 & 6 with [1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0], which won't fit, however the left box is not allowed to increase it's initial computed width, but only to decrease it.
https://github.com/chartjs/Chart.js/blob/master/src/core/core.scale.js#L477
The solution works because there is already a 2 pass computation stage. The only difference is that for the left and right boxes the initial fitting height is increased. I doubt the same situation can present itself again.

[simonbrunel]

I'm fine with that fix, can we add regression tests in core.layoutService.tests.js?

[jcopperfield]

I could add a test case to scale.linear.tests.js.

[simonbrunel]

Seems to make more sense in core.layoutService.tests.js since it could affect any scale, right?

[jcopperfield]

Not so sure it affects all scales. It is the linear spacing spacing that is causing the problem. Logarithmic scale labels always have the same format.

[simonbrunel]

What I mean is that the code you fixed is ran against all scales (actually layout boxes) and so the associated unit test should be in core.layoutService.tests.js even if the test will explicitly setup a linear scale. It will also be easier to locate when referring to the same source file.

[jcopperfield]

That I understand, the whole point of the PR is that it doesn't change anything for the end result in normal operation.
It is a real obscure bug that passes through at least 5 functions that might be able to behave differently.
I don't know how to write a regression test that would partially trigger this bug.

[jcopperfield]

@simonbrunel What kind of test would you like to be performed in core.layoutService.tests.js that would test the initial vertical box fitting?

[etimberg]

@jcopperfield would it be possible to create a test that initializes the canvas similar to the chart at the very top right. Then the test could assert that the y axis is wide enough to show the labels.

Edit: realized my suggestion was what you already implemented.

Thoughts @simonbrunel @benmccann ?

[simonbrunel]

I would simply move the test you already wrote in the layout suite.

[simonbrunel]

Thanks @jcopperfield

[jcopperfield]

Issue #4623 is a duplicate of issue #4441. Both should be fixed by this PR.