Animation flickers back and forth

[davidkarlsen]

See video on https://www.dropbox.com/s/lfyr7jv8n6dwzur/Screen%20Recording%202019-05-22%20at%2010.34.26.mov?dl=0

Running with chart v1.1.13 which is karma 0.34: https://github.com/helm/charts/blob/master/stable/karma/values.yaml#L9

[prymitive]

There's an event listener on browser width changes that triggers grid size/count recalculation, looks like this is creating a loop. Does it happen always or with some specific window width?

[davidkarlsen]

I just noticed it this time (and then it was several alerts) - usually it is clear.
I mostly run in "full-screen" (e.g. not covering full desktop - but maximized).

[prymitive]

Should be fixable with a tiny amount of refactoring so width is calculated consistently, will look into it next week

[prymitive]

Raised #732, are you able to test it? If not let's keep this open until the next release

[davidkarlsen]

Not so easy to test for me without the same alerts firing

[prymitive]

Let's merge it and see if it helps, should be a no-op for everyone not affected by this issue

[prymitive]

Released v0.38, please re-open if you notice same issue with that version

[davidkarlsen]

helm/charts#14343

[prymitive]

This is still happening, just hit this on my production install.
Looks like it gets triggered by this loop for me:

• new group added or removed
• extra group triggers the scrollbar to be visible or hidden
• scrollbar needs to be now visible or hidden, which changes the width of the grid area
• change is grid width triggers alert group card resize - potentially pushing it below or above the "minimal group width" config option which affects how many columns we render
• all these changes affect the scrollbar again and we loop over

I can stop it by changing the "minimal group width" option value, so looks like it's the self feeding loop created by going below/above the "minimal group width" threshold.
I need to find a way to reproduce this and have a regression test.

[xkilian]

Any chance you will be looking at this issue. We are hitting this with 0.33 up to 0.44.

[prymitive]

Didn't have the time and energy to look into this, especially that moving the slider for minimum group width stopped it for me. Will try to look into it this week

[xkilian]

I would suggest as a starting point to have the minimum group width exposed in the karmal.yml configuration file. At least we could set a sane default width for our most common screen setups.

[prymitive]

Added a test that simulates a resize loop in #970 and added code to adjust width calculations when that happens. It fixes the problem in tests but please re-open if you find this behaviour still happening in real world. Thanks

[xkilian]

Great. I will test the next release and provide feedback.

[xkilian]

When a loop happens it will kind refresh a couple times and stabilize. It is not pretty but it works.
The fix breaks expanding alerts. For example if an alert group has 20 elements, clicking the plus to see al elements will not work the first or send time due to some window shuffling. After a third time it usually works.

i would reiterate my suggestion of having the minimum group width exposed in the karmal.yml configuration file. At least we could set a sane default width for our most common screen setups. while this issue is being resolved.(I think it helps)

[prymitive]

Adding a way to provide default for all the toggles in the UI settings modal is a reasonable request, so I'll work on that when I have a chance.
I'll also need to dig a little deeper into that resizing issue, I need to find a better way to avoid it, rather than add safety checks to mitigate it, maybe reserve some width for scrollbars when calculating the number of columns.

[prymitive]

Merged #986 with (hopefully) a better fix for this issue.
Still need to add config options for UI defaults

[prymitive]

UI defaults are now configurable