getScrollBarWidth occasionally returns 100 when failing to calculate the width via clientWidth

[yagottahavehart]

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

[xobotyi]

Weird =/ ill add a fallback for that case.
Ty for bugreport.

[yagottahavehart]

Thank you!

[xobotyi]

@yagottahavehart write here on any results pls.