Scrolling to element uses wrong parent container if overflow-x: auto

[baohouse]

After stepping through the code line-by-line, there was a situation where reactour wasn't scrolling to the target element further down the page. So it turns out the way scrollparent works is that it checks ancestor elements for the "overflow", "overflow-x", and "overflow-y" CSS properties, looking for "auto". See olahol/scrollparent.js#7

However, there is a funky situation where if one of the ancestors is set with an "overflow-x: hidden", it causes the "overflow-y" to become "auto". https://stackoverflow.com/questions/18135204/setting-overflow-y-causes-overflow-x-to-change-as-well
Thus this container becomes the incorrectly flagged scrollable parent. You can't even force a CSS override for "overflow-y" to be "visible"; every browser will change it to "auto"!

Right now the workaround is for me to override the CSS for the wrongly-detected container and set overflow-y to "hidden" (I can't set it to "visible" because overflow-x MUST be "hidden" because I'm using a third-party UI library, but I'm worried this will just cause unforeseen bugs down the road.

[elrumordelaluz]

Hi @baohouse, thanks for open the Issue and for the investigation.

There was some similar situations where UI libraries use overflow and the scroll behaviour didn't work as expected. So, I assume your investigation is super valid. Do you have a reduced reproduction (using that UI lib) in order to debug and better to improve the Reactour behaviour?

Thanks in adavace,

[baohouse]

@elrumordelaluz Yup, quite easy. Just add overflow-x: hidden to the root element in the demo.
https://codesandbox.io/s/reactour-demo-template-live-o53bu

[elrumordelaluz]

right! but in that case you aren't using an external UI lib, so the easy solution is to set the overflow values back (ie. an advice in Readme).

[baohouse]

Ah true, I can use onAfterOpen/onBeforeClose to temporarily override/restore the CSS property on the wrongly selected container. This will have to do for now.