-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scrollYOffset with floating point number #1129
Comments
What do you mean by |
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 |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: