Lightning Web Security Issues on Row Reorder in Grid

[jack sheldon-reid]

Hi, we're noticing an issue with Salesforce support when Lightning Web Security (LWS) is disabled. When using row reorder, when attempting to reorder a row and aborting the drag an uncaught error is thrown if LWS is disabled. This error comes from the abortTranslateDrag method with the error in console being "p.getAnimations is not a function at eval". Since the abortTranslateDrag method is quite large its not something we really want to be overriding. A fix for this on this method would be updating the following line:

// before:
if (element.getAnimations().length) {

// after:
if (element.getAnimations?.().length) {

This would result in the situation where the animation results in an error, just ending the animation rather than the operation causing the grid to fail. If this could be looked into, that would be appreciated.

Thank-you, Jack Sheldon-Reid

[mats]

Thanks for reporting this. Can you please paste the full call stack?

[Animal]

It looks like this standard DOM API is somehow not present on an Element: https://developer.mozilla.org/en-US/docs/Web/API/Element/getAnimations

The code in abortTranslateDrag has

                if (element.getAnimations().length) {
                    await EventHelper.waitForTransitionEnd({
                        element,
                        property     : DomHelper.getPropertyTransitionDuration(element, transitionProperty) ? transitionProperty : 'all',
                        thisObj      : me,
                        once         : true,
                        timeout      : 300,
                        runOnDestroy : true
                    });
                }

There are a couple of usages of getAnimations() in the codebase. But what other standard DOM APIs should we only use conditionally?

[jack sheldon-reid]

Hi Animal, Theres a list salesforce have for what functions salesforce support on SecureElement. https://developer.salesforce.com/docs/component-library/tools/locker-service-viewer

Also here's the stack trace, though im not sure how useful it will be since the code is minimised on the org im using at the moment.

ee (all.lwc.js:1)
a (all.lwc.js:1)
(anonymous) (all.lwc.js:1)
(anonymous) (all.lwc.js:1)
abortTranslateDrag (all.lwc.js:3)
(anonymous) (all.lwc.js:3)
ee (all.lwc.js:1)
a (all.lwc.js:1)
(anonymous) (all.lwc.js:1)
(anonymous) (all.lwc.js:1)
(anonymous) (all.lwc.js:3)
ee (all.lwc.js:1)
a (all.lwc.js:1)
Promise.then
ee (all.lwc.js:1)
a (all.lwc.js:1)
eval (all.lwc.js:1)
eval (all.lwc.js:1)
finishTranslateDrag (all.lwc.js:3)
onMouseUp (all.lwc.js:3)
f (all.lwc.js:1)
o (aura_prod.js:92)
t (aura_prod.js:28)

[alex.l]

HI,

Thank you!

Will be fixed! https://github.com/bryntum/support/issues/11135
You can subscribe on ticket updates to be notified when it's done.

[gbrdhvndi]

It looks like this standard DOM API is somehow not present on an Element: https://developer.mozilla.org/en-US/docs/Web/API/Element/getAnimations

It is a standard DOM API, yes. Unfortunately though, Salesforce's Locker Service is nothing like standard. Components running in this mode don't get access to real Window, Document, Element or Event instances. Instead, those are replaced with artificial SecureWindow, SecureDocument, SecureElement, and SecureEvent. Those custom implementations don't support all DOM API properties and methods, so it is worse than jsdom in this regard.

When Lightning Web Security is enabled, the real window, document, and the rest are wrapped in proxies which enforce various security rules, so they are less restrictive at the cost of some performance loss. But in Locker we are very much constrained, and Salesforce has no plans to resolve this. Their long-term goal to move everyone to LWS eventually, but this won't happen overnight.

[alex.l]

Thanks for the clarification, Aleksei!

[Josh Argent]

Hi, please can we have an update on the progress of this bug? We would like to upgrade to a later version but are blocked because of this issue. Thanks

[alex.l]

Hi Josh Argent,

No news yet, unfortunately. Didn't you find a fix with 1-line change for that or it's still blocking you? It's important to set a prio for this.

[Josh Argent]

The 1-line change Jack shared above is a suggested change to Bryntum's internal code (abortTranslateDrag in DragHelperTranslate)
We could theoretically do an override patch but the function it is part of is quite large and we would like to avoid such a large override.