scrollYOffset with floating point number

[m-mohr]

I've got a ReDoc instance running with scrollYOffset set to an header element. It seems that if the height of the header element is not a integer, but a floating point number the menu gets blurred a bit.

The problem occurs if you specify an element for the scrollYOffset which el.getBoundingClientRect().bottom returns a non-integer number for. It seems that in some places it works on integers and in some on floating point numbers and this leads to imprecision when calculation the scrolling position for the menu. Using Math.ceil or Math.round in normalizeScrollYOffset solved the problem for me. So I'd suggest only allowing integers as scrollYOffset and ensure in code that it is always an integer.

Hope this can be solved soon, thanks in advance!

Seems similar to #748

[RomanHotsiy]

What do you mean by blurred? Could you share a screenshot?

[m-mohr]

Sure @RomanHotsiy, left is "blurred", right is "normal". Blurring only takes place after you scroll down at least one pixel.

Fixed it for now for me by setting scrollYOffset to () => Math.round(document.querySelector('header').getBoundingClientRect().bottom) instead of just specifying the element header. But I'm not sure whether Math.round() really works all the time, especially if the fraction is < .5. Maybe it needs to be Math.ceil(). The header has a height of 58.67... in my case and thus always rounds up so not sure about what happens when rounding down.

[m-mohr]

Interestingly, today I had a very similar issue on StackOverflow. Having seen that, I realized that this only happens in my Chrome instance, not in Firefox.

[lornajane]

I can't replicate this problem with the current version of Redoc and this issue has been open for a while, so I'm closing it. If that seems incorrect and things still don't look right, open a new issue and let us know what version of Redoc you're using now, and what seems wrong.