Open cmazereau opened 2 years ago
@cmazereau do you have a reproduction? I am not seeing this issue on https://shepherdjs.dev/
On https://shepherdjs.dev/, it seems that the issue does not reproduce because no scrollParent
is found.
But by setting the css property overflow
of the body
element to "auto", I could reproduce the issue on https://shepherdjs.dev/.
@cmazereau gotcha, if you have a fix in mind, would you mind opening a PR?
@rwwagner90 I don't have a satisfying fix just yet; I'm still trying to understand what exactly causes this behavior (after further investigation, it seems more complicated than I initially thought).
I had a little bit of time to look into this today, and found out that the problematic behavior happens when :
scrollParent
is expressed in percentagescrollParent
's parent has no explicitly specified height, and has a position different from "absolute" or "fixed"In this case, the height property should, from my understanding, behave as "auto" (cf https://www.w3.org/TR/CSS2/visudet.html#propdef-height).
But it seems that the scrollParent
actually behaves as if it were the root element (its height is expressed in percentage of the viewport - not of its content), even if it's not the "html" element.
So if the element to highlight is inside an overflown portion of the page, the function _getVisibleHeight()
will consider this element to be invisible (unless the scrollParent
's height is set to more than 100%), and the overlay will not show the expected opening.
I don't really know how to solve this. As a workaround, I have (for now) removed the css overflow
property on my current scrollParent
element, so that no scrollParent
is found.
@cmazereau sounds like a possible browser limitation or bug?
@rwwagner90 I'm not sure it's a bug or a browser limitation, since I have the same behavior on 3 different browsers:
When an element to highlight is outside of the initial window (and needs to be scrolled to), the overlay covers this element.
It appears that the svg path of the overlay is calculated using
_getVisibleHeight()
, which returns 0 in that case. This seems to be due to the fact that_getVisibleHeight()
usesscrollParent.getBoundingClientRect()
, without takingwindow.scrollY
into account. The modification of_getVisibleHeight()
as follow seems to resolve the issue :