Provide more information in error

[istoyneva]

This error is cropping randomly. Adding more info about the "logicalElement" argument that could not be processed would go a long way:

https://github.com/dotnet/aspnetcore/blob/35013f76e4eed9fdbdc40dce2373ac256c216af1/src/Components/Web.JS/src/Rendering/LogicalElements.ts#L313

[javiercn]

@istoyneva thanks for contacting us.

Do you have a minimal repro as a public github repository that we could take a look at? Is your app modifying the DOM via JS (though a library or JS interop)?

[istoyneva]

While preparing to answer your questioonquestions, @javiercn, this is a Blazor app and I noticed that it's under aspnetcore. Do we need to move it?

[istoyneva]

Again - this is a Blazor 8 SSR interactive.

There is more errors in the browser console. They're of the type:

The issue is not readily reproducible and we don't have a minimal project that experiences it.

Our code does not modify the DOM using javascript, but we use a third-party control library and I can't say what they're doing.

Could someone provide possible approaches to configure the application to capture more info around the issue? Kinda like to create dumps (client or server) or similar...

Looking at the server application log, the issue always happens after OnInitializedAsync of our main component. During OnInitializedAsync we do initialize control's binding data sources. Markup was such that the controls (in-house components plus multi-select drop downs, date pickers, grid from the third-party library) are rendered as soon as all injected properties are not null: ` @if (_modelA is not null && _modelB is not null, ...) {

... combination of our constrols and the third-party controls

} `

We're trying a different condition now - one that'd disable rendering for a little longer - until after OnInitializedAsync is fully complete.

[javiercn]

@istoyneva thanks for the additional details.

Our code does not modify the DOM using javascript, but we use a third-party control library and I can't say what they're doing.

Is this a public third-party control library? You can check if its loading JS on to the page, and see what that JS is doing.

One way to try and reproduce this, is by (if you are able to) trigger it once (record the steps) and then start removing elements from the page until you can no longer reproduce it.

The other thing you can do is search for the error and put a breakpoint in JS before it happens. You should see the nodes that it is complaining about in the page and see where in the app is happening in the element selector, and from them identify the problematic component

[istoyneva]

Is it possible to suggest where to set the breakpoint?

The issue is always gone on a re-try, so even if we stumble on it, by the time we set the breakpoint and refresh, it'll be gone

[istoyneva]

Here's what the error call stack is:

It's blazor.web.js and the error context is entirely dependent on the data received - there's not much I can get out of the javascript. Logging/tracing in the directly affected methods is also not helpful or not existing at all.

Is there a way to enable the debug-level logging visible in Microsoft's code? For example the anonymous frame from the screenshot contains _ths.logger.log(Ft.Debug, ...)

r.on("JS.RenderBatch", (async(e,t)=>{
                    var n, o;
                    this._logger.log(Ft.Debug, `Received render batch with id ${e} and ${t.byteLength} bytes.`),
                    await this._renderQueue.processBatch(e, t, this._connection),
                    null === (o = (n = this._componentManager).onAfterRenderBatch) || void 0 === o || o.call(n, On.Server)
                }

[istoyneva]

Some progress - I was able to capture (chrome .HAR file) the web sockets communication that preceded a similar error. I also saved the then-copy of blazor.web.js Is there a way to deserialize the websockets message(s) into something usable that I can feed into the js file and simulate the error occuring?

[istoyneva]

I was lucky to break and step through javascript while the error was occurring.

I then re-traced the same websocket frame being applied when the error wasn't present. In both cases it's the same URL that's visited in the browser. Please see the captures.

This looks like some sort of a timing issue, Any clues as to how to correct it?

Here's the javascript debugger state when the error is not present. This is a little earlier in the sack, actual error frame state is also shown below:

Here's the equivalent state when the error is present:

Here's the state at the error site (error not present): ... with some additional examination of the object at site:

Error site with error present:

Markup state at the time of error NOT present:

... same, but with the error present:

This is the source code - the culprit comment placeholder seems to be the Routes component outlet:

I can see the bl-root is applied here, in blazor.web.js:

This is our Routes component:

[istoyneva]

@javiercn, a lot of clues above. Can you please comment?

[istoyneva]

Here's the cause of the immediate issue inside blazor.web.js. It's important to mention that the Blazor page is running in an iframe (parent is the iframe host): "e" is the comment placeholder that is bi-root before batch #3 is applied:

Here's a rudimentary fix that illustrates the issue - instanceof Comment is failing, but comparison to Comment's object type as a string allows the processing to complete: Same fix had to be placed everywhere where instanceof Comment was used.

[mkArtakMSFT]

@javiercn what do you think about the proposed change above? Will we accept it? @istoyneva will you be open to sending a PR with the proposed change you had above?