bugfix/21131-boost-navigator-clip

[pawelfus]

Fixed #21131, missing navigator series after zooming in boost mode.

---

A follow-up to #21131 :

I bisected it to ed32adb . Apparently something similar is going on in the main pane in some of the close commits, but at least this gives us a starting point.

It comes from this commit. Tested by reverting changes and solved the issue. Why it happens? Because we have just one pane and navigator. Code executes twice, for each series:

• the main pane/series: the condition is met (width and heights are equal to the clipbox), applying clip to the parent (<group>)
• navigator: height is different, applying clipbox to the series (<image>)

The problem is: navigator series is still rendered in the series-group. That means it has two clip-rects, it's own and one leaked from main pane/series:

I don't quite understand why it's better to clip the target group @TorsteinHonsi - what is a mousewheel zoom preview? Something in HC Maps? If we don't want to revert the changes, then my suggestion is this PR: make an exception when the navigator exists. The condition is not perfect, for example, Navigator can exist in a form of a solo Scrollbar (and zero series), but is good enough.

[highsoft-bot]

File size comparison

Sizes for compiled+gzipped (bold) and compiled files.

	master	candidate	difference
modules/boost.js	14.0 kB 40.2 kB	14.0 kB 40.3 kB	5 B 13 B

[highsoft-bot]

Visual test results - No difference found

[pawelfus]

Given this pretty new bug: #21186 - perhaps there is something else going wrong. I can take a look next(-ish) week

[TorsteinHonsi]

I don't quite understand why it's better to clip the target group @TorsteinHonsi - what is a mousewheel zoom preview?

The mousewheel zoom preview is used for boosted charts with touch and mousewheel zooming, to scale up and down the image before it is dropped. Similar to the old touch-zoom functionality. So it is easier to keep the clipping fixed and scale the child element, than to scale and clip the child element.