BarChart brush selection changes while moving

[mr23]

This can be demonstrated using the Days by Fluctuation chart on https://dc-js.github.io/dc.js/. I was able to reproduce it more easily in Chrome but less so in Internet Explorer (11), but may have to do with IE11 updates were slower than in Chrome. Test was on a Win7 machine.

If you start with a selection of 3 bars

and then drag that selection left and right, at varying speeds, with some random pauses, the selection changes to fewer or more bars. I was not waiting for all charts to complete transition updates.

Normally when dragging, the cursor is a '+' shape (with arrow endpoints). At times when dragging, but without releasing mouse button, the cursor changes to a '-' shape (with arrow endpoints). It seems that dc is not maintaining the current operation state (dragging a selection) and is changing in/out of selection endpoint changes. Varying the 'x' starting position of the cursor has some effect on how quickly it can reproduce, doing the mouse-down closer to the selection endpoints causes it to reproduce sooner. I was not able to capture the cursor in a screen capture.

Expectation: Until mouse-up, dc.js should stay in drag ('+') state, and not alter the endpoints of the selection.

[gordonwoodhull]

Thanks @mr23 for the report! I can reproduce this.

Although the cursor behavior is weird, I don't think the bug has to do with mouse state.

Instead, what I think is happening is that the "brush rounding" feature is being invoked. While resizing the brush, you may notice that it snaps to locations between the bars, in this case exact percentage points and not fractions of percents.

As you wiggle the brush back and forth, it rounds the top and bottom of the brush each time a brush event fires. Then it sets the brush extent to the rounded values and also uses them for filtering.

I can't explain why this always results in the brush decreasing in size, but it it does make sense that these rounding errors accumulate. If you disable brush rounding in stock.js line 389:

        //.round(dc.round.floor)

then the bug is not exhibited.

One easy way to fix this would be to not snap the brush, but only snap the filtering. Maybe not so satisfying, though.

It's kind of hard to think how else to fix this, because changing the brush extent while we are inside a brush event is inherently unstable. Maybe if we could distinguish between a brush sizing event and a brush moving event, we could keep the size constant and apply rounding always to the known size.

Mike's brush snapping block only snaps on brush-end. Maybe a good compromise would be to round the filter during the brush move event, but round the brush only at brush-end.