[LWC] "Cannot read properties from undefined" error when reading Lightning bubbled event's property

[apinar]

Hi Bryntum teams!

We are facing an issue with Salesforce due to Lightning (probably Locker) returning undefined for getRootNode().

This happens no matter Lightning Web Security is enabled or disabled.
Clicking on a record page’s background makes Bryntum fail with a “Cannot read properties from undefined” error when capturing the DOM event that bubbles up:

Screen Recording 2023-05-30 at 11.39.55.mov

(3.36 MiB) Downloaded 125 times

This is causing the error to be caught by Salesforce some times, getting to the end user. This has been reported by some of our customers though we haven’t been able to reproduce it in our development environments:

Screenshot 2023-05-22 at 09.36.19.png (211.29 KiB) Viewed 4292 times

A possible fix would be to use optional chaining when reading the host property: target?.getRootNode?.()?.host.

Screen Recording 2023-05-30 at 11.49.53.mov

(3.64 MiB) Downloaded 107 times

There is a related issue currently opened. If fixed, it won’t fix ours though: https://github.com/bryntum/support/issues/6696

Thanks!

[Maxim Gorkovsky]

Hello.
I won't even try to reproduce this problem, if even you cannot do it knowing your application. Judging by the stack trace, I can see a single place where it would be safe to add optional chaining:

if ((target?.shadowRoot || target?.getRootNode?.().host) && event.composedPath) {

I will update it and let's hope it also fixes issue on your end too.

You can try to fix this one too, all you need to do is locate this method in the bundle, copy it entirely and use in the EventHelper override instead of _overridden.fixEvent.call(...) call

[Maxim Gorkovsky]

I opened ticket here: https://github.com/bryntum/support/issues/6877

[apinar]

Thanks a lot Maxim!

The fixEvent is exactly the one that is causing the issue. As you can see in the second screen recording, adding an optional chaining such as target?.getRootNode?.()?.host fixes it from our end.

That was a really fast fix, we loved it!

[gbrdhvndi]

Here is what I learned about this issue so far:

• It only happens on flexi pages with custom templates (those are Aura components, not LWC).
• Calling getRootNode on the original event’s target (before Locker intervention) returns a document fragment (Aura component boundary) to which Bryntum code has no access, and so the Locker returns undefined instead.
• This works on pages with standard templates because those are composed differently, so calling getRootNode() on the original event's target returns the body element, which Locker is happy with and replaces it with a "secure element" rather than blocking access entirely.

A quick workaround would be to add optional chaining to target?.getRootNode?.()?.host as suggested above, but this would make the if condition in EventHelper.fixEvent() evaluate to false, so the custom target and originalTarget properties will not be defined on the fixed event.

If that is an acceptable behaviour, then this workaround should be good enough. Otherwise consider switching from calling target.getRootNode() directly to using DomHelper.getRootElement(target) which internally calls getRootNode() but offers some extra protection. A Salesforce specific override of getRootElement is already available, it can be tweaked independently to handle more edge cases if necessary.

[Maxim Gorkovsky]

getRootElement works different from getRootElement, so I'm afraid we cannot just replace it everywhere. Judging by the video it seems that issue was caused by clicking outside of the Bryntum component (I don't remember even seeing one on that page). I suggest we see if any feature stops working and then take necessary steps. As I understand, everything seems to be functional so far, isn't it?

[gbrdhvndi]

Unfortunately, this does not appear functional to our customers. The error message dialog appears in customer's production environment. We are not sure exactly why it is not showing in a scratch org. This is probably due to the dev code being unmanaged, but the error can be caught using the "stop on exceptions" setting.

This only happens on pages that are configured with a custom template, which is why we never caught it before.

If DomHelper.getRootElement() works differently to element.getRootNode and we cannot use one in place of another, then some extra optional chaining in EventHelper.fixEvent() should do the job. As I understand, this is how this issue has been addressed already. I only tried to understand the root cause and offer an alternative solution.

P.S.
The Bryntum component in the video is the Grid – it's just styled using our custom theme and also features some custom cell renderers, so it may be difficult to recognise.

[Maxim Gorkovsky]

I see. Thank you for your investigation, it does provide useful context. We did apply another optional chaining as suggested above, let's see if there are negative implications to this solution. If there are - we can look for a better alternative. Thanks!