You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the current behavior?
New implementation of getScrollWidth causing occasional issues resulting in a margin-right of -100 set to the scrollbar, when something around 15-20 would be appropriate.
Steps to reproduce/debugging/Suggestions
Unfortunately, we've noticed this deep in our site & don't have a reliable way to reproduce it. The content in question is located within an iFrame and the though is that the width calculations are happening before it's fully mounted.
I believe it's related to the change in Commit: 543bbd4
Specifically, scrollbarWidth = el.offsetWidth - el.clientWidth; was replaced with getScrollbarWidth._cache = 100 - el.clientWidth; in this commit.
When stepping through, el.clientWidth occasionally returns 0 (instead of the expected 80/85), which worked previously because el.offsetWidth returned 0 as well, resulting in the fallback width of 20.
Note: putting a breakpoint after the doc.body.appendChild(el) gives the site enough time to load & the correct value is returned from el.clientWidth
Not sure the correct solution here to harden the automatic getScrollbarWidth, but a value of 0 for el.clientWidth does not seem like it should be respected and perhaps should result in the fallback
A little about versions:
OS: OSX 10.14.5 (18F132) (though have seen it across a couple versions)
Browser (vendor and version): Chrome Version 77.0.3865.90 (Official Build) (64-bit)
React: 16.10.1
react-scrollbars-custom: 4.0.20
Did this worked in the previous package version? Yes, 4.0.18
The text was updated successfully, but these errors were encountered:
What is the current behavior?
New implementation of getScrollWidth causing occasional issues resulting in a margin-right of -100 set to the scrollbar, when something around 15-20 would be appropriate.
Steps to reproduce/debugging/Suggestions
Unfortunately, we've noticed this deep in our site & don't have a reliable way to reproduce it. The content in question is located within an iFrame and the though is that the width calculations are happening before it's fully mounted.
I believe it's related to the change in Commit: 543bbd4
Specifically,
scrollbarWidth = el.offsetWidth - el.clientWidth;
was replaced withgetScrollbarWidth._cache = 100 - el.clientWidth;
in this commit.When stepping through,
el.clientWidth
occasionally returns 0 (instead of the expected 80/85), which worked previously becauseel.offsetWidth
returned 0 as well, resulting in the fallback width of 20.Note: putting a breakpoint after the
doc.body.appendChild(el)
gives the site enough time to load & the correct value is returned fromel.clientWidth
Not sure the correct solution here to harden the automatic getScrollbarWidth, but a value of 0 for
el.clientWidth
does not seem like it should be respected and perhaps should result in the fallbackA little about versions:
OS: OSX 10.14.5 (18F132) (though have seen it across a couple versions)
Browser (vendor and version): Chrome Version 77.0.3865.90 (Official Build) (64-bit)
React: 16.10.1
react-scrollbars-custom
: 4.0.20Did this worked in the previous package version? Yes, 4.0.18
The text was updated successfully, but these errors were encountered: