Diversity panel extends beyond genome end on 3' end

[corneliusroemer]

Current Behavior

The diversity panel x-axis extends beyond the 3' end of the genome.

e.g. for SARS-CoV-2 it goes roughly 150 bases beyond the 3' end at 29903 (Wuhan-Hu-1)

This is asymmetric with the 5' end, where it starts at 0 and doesn't go negative:

Expected behavior

The position axis does not extend beyond the genome end (at least not more than a few bp)

The fact that the axis extends creates the user impression that the real genome is longer than it actually is, and that there is a lack of mutations - when in fact there can't be any mutations in this non-existent region.

See in our ncov builds: https://next.nextstrain.org/ncov/gisaid/global/1m?gmin=29677&l=unrooted&m=div

[jameshadfield]

Notes after a quick investigation into this. Relevant provided data (for nCoV):

“nuc”: { “start”: 1, “end”: 29903, ...
“N”: {  “start”: 28274,  “end”: 29533, ...

The lower scale (xNav) correctly sets and maintains a domain of [0, 29903]. The upper scale (xMain) starts with the same domain (assuming no URL query params). All ticks are managed by d3's axisBottom.

There's some space to the right of the lower scale which we can drag the selection box into, which is the cause of this bug. As we drag the selection to the RHS, this function calculates zoom coordinates as high as ~30,036. This has the flow-on effect of changing the domain of the upper scale (here), which is why d3 shows the tick at 30,000bp on the upper axis. The zoom selection can go further than the axis domain due to this code:

auspice/src/components/entropy/entropyD3.js

Lines 484 to 486 in 9b8b684

	this.brush = brushX()
	/* the extent is relative to the navGraph group - the constants are a bit hacky... */
	.extent([[this.offsets.x1, 0], [this.offsets.width + 20, this.offsets.heightNav - 1 + 25]])

however removing the 20px of padding here introduces another problem (we can no longer drag the selection far enough), presumably the reason for this hack in the first place. I can mostly solve the bug by forcing the zoomCoordinates to never exceed the axis domain, but if we can work out why this hack is needed in extent() that would be the best.

[emmahodcroft]

I have a vague memory of also coming across this [that without some extra space you can't drag far enough] when I did some work on the diversity bar way back in the day.