[Blazor] InputText binding is not supported well with Shadow DOM elements

[Poppyto]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I use a web component library which create input elements within shadow DOM (shadowRoot property).
Let's call it <super-input>
I overrided InputText content with .

When using @Bind on the value with oninput event, it doesn't work as well as the InputText or html input element. Characters could be sent weirdly depending the connection, and the use or websocket or no, and specially when the typing is fast.

I already digged into the problem and found a fix on my branch : https://github.com/Poppyto/aspnetcore/tree/poppyto/use-shadow-input-with-binding

The idea is to relay on event.composedPath().find(_=>true) instead of event.target when dealing with some events.

I would be happy to discuss about this bug

Expected Behavior

The typing must be smooth

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8

Anything else?

No response

[javiercn]

@Poppyto thanks for contacting us.

Is there an error on the console or something that indicates the problem? I think using composedPath might be an option, but we'll need to better understand what is currently failing and why, and whether this is something that we would apply on all cases or selectively.

[Poppyto]

Problem happens if you want to to override InputText with other control than (HTMLInputElement), let's say <super-input> which has a shadow <input type='text'> inside.

The problem is easy, and you can reproduce it like that - without creating a shadow control :

• Make sure to not use Websocket in startup

 app.MapBlazorHub(options =>
 {
     options.Transports = HttpTransportType.LongPolling
                          | HttpTransportType.ServerSentEvents
                          // | HttpTransportType.WebSockets
                          ;
 }).WithOrder(-1);

• create a MyInput.razor component which handle oninput when binding the value

@inherits Microsoft.AspNetCore.Components.Forms.InputText
<input @attributes="@AdditionalAttributes" class="@CssClass" @bind="@CurrentValueAsString"
       @bind:event="oninput" @ref="Element" />

• return null from EventFieldInfo.fromEvent (you can edit inside blazor.web.js within the Inspector, then Save)
• Throttle the browser to 3G network speed.
• Type fastly in the input field and observe the problem (Same as old issue Components bind-value-oninput can lose cursor position with fast typing #8204)

So this issue will happen with shadowed input controls as the EventFieldInfo.fromEvent method is looking for HTMLInputElement in the event.target. With shadowed input control, event.target will always be <super-input> and it will break the binding update in time. That's why I suggest to use composedPath to make sure to have real input controls involved by the binding

[javiercn]

@Poppyto thanks for the additional details.

You are mentioning a few things that I don't seem to understand.

Make sure to not use Websocket in startup

 app.MapBlazorHub(options =>
 {
     options.Transports = HttpTransportType.LongPolling
                          | HttpTransportType.ServerSentEvents
                          // | HttpTransportType.WebSockets
                          ;
 }).WithOrder(-1);

Using the old MapBlazorHub extension with blazor.web.js is not supported. Similarly, we require you use websockets.
Throttle the browser to 3G network speed.

Does this issue not reproduce when using websockets as the transport? I would have expected this issue to be completely independent of the transport layer used by signalr or the connection speed. Can you confirm that the issue reproduces without those two conditions?

Ideally this is something a test can be written for that should pass or fail in all different environments (server, webassembly, webview). As far as we understand the issue is with the shadow-dom, so none of the other things should matter.

If we can scope a change that detects we are inside a shadow DOM and go through the alternative path (composedPath as opposed to event.target) I think we would be fine with that

[Poppyto]

The problem also occurs with Websocket, it is just a bit more difficult to test (you have to create a custom very slow connection within the console developer) - my goal is to make the problem easily reproducible.

But let's go back to the real issue, I think the easiest way is as my commit does, check the event.composed existance before using event.composedPath, and use event.target otherwise. It will work for both scenarios, HTMLInputElement or shadowed HTMLInputElement