The <Virtualize> component supports using the document itself as the scroll root (as an alternative to having some other element with overflow: scroll). However when using the document as the scroll root, it's necessary not to have overflow-y:scroll on the <html> or <body> elements, because doing so causes the intersection observer to treat the full scrollable height of the page as the visible region, instead of just the window viewport.
You can repro this problem by creating a very large virtualized list (e.g., 100000 items) and then trying to use the document as the scroll root and having html { overflow-y: scroll } in the page CSS. Although it may settle down and start working, at least one time at the beginning it will try to render all 100000 items which may cause a browser tab lockup.
Proposed solution
In the findClosestScrollContainer logic where we locate the scroll container, we should special-case document.documentElement. That is, if the recursion gets all the way up to the <html> element, then we should not return that. Instead, we should return null so that the IntersectionObserver's root parameter is null, which means "viewport" as opposed to "whole scrollable height of element".
I think it's too late and risky to do this in 6.0 but will be a very trivial fix in 7.0.
Workaround
People using 6.0 can either not put overflow-y:scroll on the html/body elements, or can fake it with some alternative like:
html {
min-height: calc(100vh + 0.3px);
}
The
<Virtualize>component supports using the document itself as the scroll root (as an alternative to having some other element withoverflow: scroll). However when using the document as the scroll root, it's necessary not to haveoverflow-y:scrollon the<html>or<body>elements, because doing so causes the intersection observer to treat the full scrollable height of the page as the visible region, instead of just the window viewport.You can repro this problem by creating a very large virtualized list (e.g., 100000 items) and then trying to use the document as the scroll root and having
html { overflow-y: scroll }in the page CSS. Although it may settle down and start working, at least one time at the beginning it will try to render all 100000 items which may cause a browser tab lockup.Proposed solution
In the
findClosestScrollContainerlogic where we locate the scroll container, we should special-casedocument.documentElement. That is, if the recursion gets all the way up to the<html>element, then we should not return that. Instead, we should returnnullso that theIntersectionObserver'srootparameter isnull, which means "viewport" as opposed to "whole scrollable height of element".I think it's too late and risky to do this in 6.0 but will be a very trivial fix in 7.0.
Workaround
People using 6.0 can either not put
overflow-y:scrollon thehtml/bodyelements, or can fake it with some alternative like: