[Blazor] Virtualization does not work with web components

[czdietrich]

Describe the bug

Blazor's Virtualize component tries to find the surrounding scroll container by moving up the elements tree and look for an element where overflow-y != visible. (see here)

Unfortunately that way it will not find scrollable containers within web components, since it never checks for the shadow root on any element.

Expected Behavior

Virtualization should also just work for custom scroll containers that are built using web components.

pseudo html:

<div>
  <my-custom-scroll-viewer> <!-- shadow root contains an element with vertical overflow -->
    <Virtualize Items="..." />
  </my-custom-scroll-viewer>
</div>

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

6.0.400

Anything else?

No response

[SteveSandersonMS]

@czdietrich A shadow DOM can operate as either open or closed. Do you know which one applies in your scenario?

My guess is that:

• If it's open, then Virtualize would work with it automatically, since it would see the DOM element that has the overflow rule
• If it's closed, then Virtualize would not be able to see the DOM element that has the overflow rule, so it couldn't be expected to work. If you have a suggestion for how it should be able to see the overflow element in this scenario, could you clarify how?

If I'm misjudging this and there is some basic bug in Virtualize that stops this working when it should work, could you create a simple repro, for example using https://blazorrepl.telerik.com/?

[SteveSandersonMS]

Oh wait, maybe it doesn't work even for open shadow roots, since we don't go walking through all the .shadowRoot properties on every element as we traverse the DOM.

If you have a suggested implementation for how this should work, please let us know and we could assess it. Otherwise this seems like it would be a valid feature request, but would likely stay on the backlog unless there was more community feedback.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[czdietrich]

Hi @SteveSandersonMS, in our scenario the shadow DOM is open, so Blazor could walk into it, but unlike WPF, you need to explicitly look for the shadowRoot properties as you mentioned.

Some important point I missed is that the Virtualize component is broken in current Firefox for us when the scrollable area is encapsulated within a web component. By broken I mean it does not display any item, since the ItemsProvider-callback of the Virtualize component requests zero items in Firefox only. It is working fine in Chrome and Edge. And it did also work in Firefox 103.x, but suddenly broke with the latest Firefox update 105.x.
This all being said, it is just a guess that the issue is due to use of web components, it is just our current observation that it suddenly breaks with the newest Firefox release and that it seems to work without using a web component.

I'll try to dig deeper into the issue and try to make a minimal repro to demonstrate the issue.

[czdietrich]

Firefox 104.2 was also working. Maybe it is a bug in the latest Firefox?

[czdietrich]

OK, I got some more info here.
There are two things mixed up.

First, there seems to be a breaking change (most probably a bug) in current Firefox (105.x) what breaks the current logic in Blazor's Virtualize component to find the closest scroll container. The condition to check for getComputedStyle(..) !== 'visible' does not work and will always return the initially passed element as scroll container, which is the upper spacer of the Virtualize component.

See the behavior of getComputedStyle(..):

Edge 106:

Firefox 104:

Firefox 105:

And second, the Blazor's Virtualize component currently won't find scroll containers within web components and will fall back to the document root as scroll container. We should scope this issue only to that specific problem as stated in the initial issue description.

I will think about a patch to also include shadow DOMs for finding the scroll container.

[czdietrich]

I have some more insights to share.

As in the previous comment stated we stumbled upon an issue with the latest Firefox in relation to the usage of the Virtualize component and as it seems to turn out, current Firefox seems to be the only browser that correctly resolves to the specification.
https://bugzilla.mozilla.org/show_bug.cgi?id=1793938

In my opinion the cause of the issue we face is that the Virtualize component tries to make assumptions about the DOM when being initialized. Currently it works for basic html to traverse the DOM to look for the surrounding scroll container. But as stated above shadow roots of web components are not yet included. Additionally, it can also fail when Blazor is used together with another framework. In our case we use a corporate web components library which is based on lit whose lifecycle is not synchronous to Blazor's lifecycle, so when the Virtualize component tries to find the surrounding scroll container, the web component might not yet have rendered its local DOM.

So, to make the Virtualize component more compatible to other frameworks we should think about alternative ways to initialize it. I could think of an asynchronous callback that could be used to provide the reference to the scroll container or something like a query selector, which would not fix the issue with the asynchronous lifecycles on its own but is just a thought.

What are your thoughts about this?

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.