ScrollSpy skips short sections

[bkdotcom]

#15729

This is still an issue that needs "solved" in Bootstrap 4

if the last section(s) are short, when reaching the bottom of the page, bootstrap will skip over anchors that didn't get scrolled to the top of the page and consider the last anchor to be "active"

[Johann-S]

Hi @bkdotcom can you provide a test case in v4 ?

[XhmikosR]

Closing due to lack of response. You can comment here and we can re-open the issue.

This is an automated reply

[bkdotcom]

I stole the bootstrap 3 example and converted it to bootstrap 4:

https://codepen.io/bkdotcom/full/vYEyeVr

[stevenbuccini]

Hello everyone! This problem seems to be heavily dependent on where the short content is on the page. The example @bkdotcom provided accurately represents the case that led me to this issue in the first place. However, if you take that same example, slice the two short <sections> and re-insert them in the second and third slots within the container div, the scrollspy works correctly.

As best as I can tell, the current logic for determining the active <div> within the scrollspy is as follows:

1. If the top of the scrollElement is at a location greater than or equal to the top of the scrollElement when you can't scroll anymore, make the last target active and return.
2. Consider each possible target, working from the bottom of the page
3. If the top of the scrollElement is beneath the top of the considered target AND the top of the scrollElement is beneath the top of the previously considered element, mark the current index as active.
4. Else, change your target to the next element further up the page and repeat step 3.

(The logic is in the _process method, with the check on line 234 being the interesting case.

When stepping through the debugger on the provided example, it's clear that the bottom of the scrollElement is reached, triggering the short-circuit logic in case 1, before the smaller divs have a chance to have the top of their bounding box reach the top of the scrollElement which would make them active.

The key insight here is that you can't actually scroll through the total height of the scrollElement amount of space, but rather total_height - amount_viewable_at_any_given_time.

This suggests the trivial fix, which is just add an empty element with a height of _getOffsetHeight() as this would allow you to scroll every target up to the top of the scrollElement. Obviously, this would leave a lot of white space and wouldn't provide a great UX.

One alternative would be calculate the percentage height that each target makes up of scrollElement height. Then, as the user scrolls, we can calculate the relative amount they've scrolled compared to the maximum possible scroll distance. Then, we can use the same comparison logic that's already in place to figure out what bucket we're in.

What do y'all think? I'm happy to put up a PR if we can agree on an approach.

[dmitchellmim]

@stevenbuccini would your proposed fix handle the case where you click on an anchor link, rather than scrolling to it manually? In the test case, for example, clicking on the penultimate "Cat ipsum" activates "Batman ipsum", even though it's not the one you clicked on. That behavior is less intuitive than when scrolling manually, in my opinion.

[stevenbuccini]

I can't say with certainty as I haven't looked at this in several months. However, it seems like clicking an anchor link directly should bypass the height offset calculations entirely and simply call _activate() on the appropriate target.