Given that the default height of a track is just 100 pixels this is often a good thing to have. Otherwise users have to manually use the track resize handle to increase track height

Proposal for this:

• when a track is opened for the first time, it can auto-adjust its height during the time in which not all of its visible blocks are loaded. After that, its height is solely under the user's control.
• when a session is reloaded, the tracks are at the height that's specified in the session.

what do you think about that, @cmdcolin?

My general feeling is that scrolls within scrolls is generally a problem. We have outer scroll and then each track can have scroll. This results in difficulty in even initiating an outer scroll with a mousewheel or touchpad. So my feeling is that it's better to just have autoadjust

I have not heard of that complaint before

What I have heard is that track height was difficult to configure in jb1 and I remember Suzi requesting per track scroll but I feel there are downsides to having too many scrolls

Do you propose going back to the way JB1 does it, just refusing to render anything else once you get "max height reached"?

I think that scrolls within scrolls that cause difficulty interacting with the outer view is my main problem. If there are other usability problems, like having the right amount of info on the screen, and having per track scroll helps, then I may be open to it.

I looked at a comparison for example igv, and it does have per-track scroll in both IGV desktop and web. The per track scroll does not respond to touchscroll though which goes a long way towards not bothering me. Weirdly, the per track scroll is quite stealthy in that way. See https://igv.org/app/ the RefSeq track actually has a scroll that is not really obvious, I looked at it and said "ah yes a gene with only two isoforms, how simple..." and then I realize it actually scrolls down.

Here is a tinyurl of an IGV web with BAM and genes http://tinyurl.com/uko8pob that has per track scrolls, and only one outer scroll

We could make the track scrolls just not respond to mouse-wheel vertical scroll events fairly easily I think, which would make it behave like igv.js is behaving there. How about we just do that?

We could try. I am not a huge fan of how it changes the semantics of scrolling to a custom more-non-functional-scroll but if I need to get over that I can. I feel like adding scroll if a user needs it is not that unintuive

Note that, preventing scroll involves some involved stuff

For one thing

onScroll and onWheel event.preventDefault do nothing, they are maybe passive?
useRef+ref.current.addEventListener event.preventDefault prevents outer scroll of the page, it halts outer scroll anywhere inside that element

I demonstrated this at one point but you can see it with a thing like this

<div id="test" style="height:1600px; width:500px;background-color:green;overflow:auto">
  <div style="height:10000px; width:500px;background-color:red;margin:20px">
    Hello world
  </div>
</div>

<script>
  document.getElementById('test').addEventListener('wheel', function(event) {
    event.preventDefault()
  })
</script>

Any wheel/touchpad scroll action of scrolling inside the red or green areas prevents outer scroll on my machine

The way to do it is to fully override any default scrolling I think, using a custom scroller that only replies to click events maybe

The comment above " I feel like adding scroll if a user needs it is not that unintuive" refers to the idea that we keep JB1 behavior for many cases, and add scrolling if needed maybe?

How about we:

• resize the track to fit its block heights during the period between when it is first opened and when all of its blocks are rendered
• implement something keep scrolled tracks from intercepting vertical mouse wheel events

That would mean that tracks, when first opened, will resize themselves to not need scrolling, but after that they will not resize and will be under user control. And when you scroll with the mouse wheel any scrolling tracks won't block that.

How about that?

I'll mull it over. It seems almost like step 1 is very much like jbrowse 1, why not just go full jbrowse 1 behavior. with step 2, it is difficult without a custom scroll as mentioned above.

Alternative to step 1: just have an opinionated stance on what a alignments track height is...on what a wiggle track height is, on what a gene track height is.

I'm going to throw my opinion in here and say that I like Rob's original proposal (adjust a track's height when it's first opened), and if you end up with a scroll within a scroll after that, it's just fine. We're using the browser default behavior for a scrollable element inside a scrollable page, so it should be what most people expect. I, personally, have never had any trouble navigating the scrollable tracks.

I think resizing the tracks on horizontal scrolling is problematic because if a track near the top resizes a lot, it could push another track that you may be looking at off the screen.

In order to perform outer scroll when you have per-track scrolls, you have to carefully position your mouse outside of any area the tracks occupy. I have a problem with this pretty much anytime there is an outer scroll present

Pages are much easier to deal with when there are not scrolls within scrolls

In order to perform outer scroll when you have per-track scrolls, you have to carefully position your mouse outside of any area the tracks occupy.

That's not the behavior I observe. If I scroll down on a track that is already scrolled all the way down, it scrolls the page instead.

@garrettjstevens I do not want to have to scroll a track to the bottom of it's per-track scroll to scroll the outer page

The way I refer to as the special location is the track controls, which will possibly go away, making this problem even more difficult

Here is a good article on the UX perspective of this issue https://baymard.com/blog/inline-scroll-areas

Sort of related https://ux.stackexchange.com/questions/102831/is-scroll-within-a-card-good-or-bad-in-desktop

Some ideas related to that article, truncation design https://baymard.com/blog/truncation-design

see also #3858

random whirlpool of sort of related concepts from weekly meeting

• transcript labels sub-layout feature labels #241
• collapsing gene glyphs (reduces track height)
• sorting transcripts in gene glyph
• change svg feature rendering to pure client side rendering...hunch is it speeds up compared to rpc system
• purpose of the max height variable...just a speedup
• add query param api to do auto adjust
• remove the 'bound' setting