[bfailing]

There’s no point in showing a screenshot. It would look like the one you posted except the black “100,000” label is hidden.

This also occurred on a Pinebook Pro (Linux laptop) in Firefox tested at 832px.

BTW, “upper-right corner of the Fiddle chart window” in my previous message should have been “upper-left corner of the Fiddle chart window”.

[bfailing]

I can’t attach a screenshot (your forum won’t allow it apparently), but this occurred at these random window sizes (from the upper-right corner of the Fiddle chart window): 832px, 1045px, and 1484px. This occurred in Firefox, Chrome, and Edge on a Windows 10 machine.

[bfailing]

This is definitely a bug. The crosshair remains displayed, but the crosshair label is hidden. In other words, it is snapping to the last data point but not displaying the value in the crosshair label.

If you can’t replicate it, try making the chart wider. Here is another example that may make it easier to see: https://jsfiddle.net/01dtnkme/. Again, if you can’t see it, make it wider.

[bfailing]

This was a double-post. It should be deleted.

[bfailing]

This issue still exists with the newest release. Any plans to fix it?

[bfailing]

You JSFiddle doesn’t replicate the situation I described. As I said, go to that page and make the changes indicated. Or you can add a second data point to what you have. Then watch the browser memory usage rise…

[bfailing]

The previously-posted code block causes the zoom to change when panning between far left and right sides of the chart (doesn’t seem to affect the rubber-band scrolling effect “mode”). Try this instead:

if (isFinite(q.dataInfo.minDiff)) {
    B = q.getApparentDifference(n, f, null, !0);
    if (!(g || !(this.panEnabled && q.scaleBreaks && q.scaleBreaks._appliedBreaks.length) && (q.logarithmic && B < Math.pow(q.dataInfo.minDiff, 3) || !q.logarithmic && B < 3 * Math.abs(q.dataInfo.minDiff)) || (this.plotArea.x1 <= q.convertValueToPixel(q.minimum) && n < q.minimum) || (this.plotArea.x2 >= q.convertValueToPixel(q.maximum) && f > q.maximum))) {
        w.push(q);
        s.push({
            val1: f > q.maximum ? n - (f - q.maximum) : n < q.minimum ? q.minimum : n,
            //val1: this.plotArea.x1 <= q.convertValueToPixel(q.minimum) && n < q.minimum ? q.minimum : n,  // enable for rubber-band scrolling effect
            val2: n < q.minimum ? f + (q.minimum - n) : f > q.maximum ? q.maximum : f
            //val2: this.plotArea.x2 >= q.convertValueToPixel(q.maximum) && f > q.maximum ? q.maximum : f  // enable for rubber-band scrolling effect
        });
        l = !0;
    } else if (!e) {
        l = !1;
        break;
    }
}

[bfailing]

In case anyone else is having this issue, you can fix it by making a few changes within their p.prototype.validateRegion function. Replace the corresponding block with the following:

if (isFinite(q.dataInfo.minDiff)) {
    B = q.getApparentDifference(n, f, null, !0);
    if (!(g || !(this.panEnabled && q.scaleBreaks && q.scaleBreaks._appliedBreaks.length) && (q.logarithmic && B < Math.pow(q.dataInfo.minDiff, 3) || !q.logarithmic && B < 3 * Math.abs(q.dataInfo.minDiff)) || (this.plotArea.x1 <= q.convertValueToPixel(q.minimum) && n < q.minimum) || (this.plotArea.x2 >= q.convertValueToPixel(q.maximum) && f > q.maximum))) {
        w.push(q);
        s.push({
            val1: n < q.minimum ? q.minimum : n,
            //val1: this.plotArea.x1 <= q.convertValueToPixel(q.minimum) && n < q.minimum ? q.minimum : n,  // enable for rubber-band scrolling effect
            val2: f > q.maximum ? q.maximum : f
            //val2: this.plotArea.x2 >= q.convertValueToPixel(q.maximum) && f > q.maximum ? q.maximum : f  // enable for rubber-band scrolling effect
        });
        l = !0;
    } else if (!e) {
        l = !1;
        break;
    }
}

Replace the commented val1 and val2 with the uncommented ones for a rubber-band scrolling effect.

[bfailing]

Clearly it’s a time zone issue, but as I said: “(e.g., from 16:00 to 16:23, but other zoom levels work too).” “e.g.” means for example, and “but other zoom levels work too” is self explanatory. Again, as an example, zoom the chart so that at least two data points are no longer visible (so that the visible range of x axis labels after the zoom in your chart go, e.g., from 4:30 to 4:51 or from 4:32 to 4:53), then try to pan to the far right of the chart.

BTW, this affects both panning to the right and left sides of the chart, but I don’t see an option to edit the title or the original post. If you don’t zoom far enough away from the right or left side of the chart initially, then it may pan properly the first time (very infrequently). If this happens, try panning to the other side of the chart and the issue will present itself. The issue is painfully obvious.

And just for fun to see if it only applied to mouse events (I was previously using a mouse on the Windows 10 machine), I just replicated it in Firefox on a Note 8 (using finger – stylus doesn’t allow me to zoom the chart). Again, try panning back and forth after the chart is zoomed in a ways.