LWC appears to be removing properties from DOM elements

[simonsarris]

Hello, I am an author of the diagramming library GoJS. Recently, GoJS has been breaking in LWC for customers due to, I think, DOM modification on LWC's part. It is difficult to debug exactly what the problem is, but it seems that LWC, at least with Lightning Web Security turned on, is removing properties from DOM elements.

In GoJS we attach a _diagram property to an HTML Div and HTML Canvas:

This is used for example during events, like dragging and dropping from one Diagram to another, to identify drop targets. It seems like LWC with web security turned on is removing this property from the DOM elements that GoJS creates, causing the events to fail.

Is this intentional behavior on the part of LWC? Is there some way LWC can prevent this modification of the DOM elements our library creates? Or some option our clients can set so that it does not happen?

[nolanlawson]

@simonsarris Thanks for reaching out! Is GoJS modifying the prototype of Div and and Canvas elements, or only the instances of those elements?

[jdalton]

From the LWS side this is seen as a 1 sided mutation. So happening inside the sandbox and not reflected in the outer-world DOM. There are a couple of options.

1. instead of bolting on properties to DOM elements you can track metadata with them using a WeakMap with the DOM element as the key and the meta data as the value.
2. You can use the dataset API: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset

[simonsarris]

Only instances (and only instances that we create).

…

On Wed, Feb 8, 2023, 7:46 PM Nolan Lawson ***@***.***> wrote: @simonsarris <https://github.com/simonsarris> Thanks for reaching out! Is GoJS modifying the prototype of Div and and Canvas elements, or only the instances of those elements? — Reply to this email directly, view it on GitHub <#3336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACTH23BQ2KBAVHDBTHOY73WWQ46ZANCNFSM6AAAAAAUV5BSKE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[simonsarris]

Thanks for the suggestions and confirmation @jdalton. We can't use (solely) dataset since we're storing references, and not just strings.

Might your sandboxing DOM manipulation break a WeakMap, too? If I create an HTMLDivElement and add it to the DOM and add an entry to my map, and the end user later fires an event over it from another DOM element, where that first HTMLDivElement is the event.target or first item of event.path, will that target === my reference? Or is that safe per your sandboxing model?

In other words, if I drag and drop between two Divs, will the PointerUp's target be the Div reference I originally created?

[jdalton]

event.target and event.path (as long as it's not inside a shadow root) should be fine. DOM/Event properties tend to work, custom expandos don't.

[caridy]

Ok, I'm confused here @simonsarris. If GoJS is evaluated inside sandbox A, and the library adds expands to DOM elements that are solely read by the library in sandbox A, there is no problem. That should work just fine IMO. The protection about expandos is between realms (meaning between sandboxes and between a sandbox and system mode). Before we look for solutions, let's try to identify the actual problem first.

You can try that in a sandbox very easily, just do:

const a = {};
document.body.firstChild._foo = a;
console.log(a === document.body.firstChild._foo); // should yield true

[simonsarris]

I am currently awaiting confirmation that a library build which uses a WeakMap instead of attaching properties to the Divs and Canvases really does solve the problem. If it does, that's good enough for me, and I will make a new release of GoJS.

@caridy Since I am simply the library developer, not a LWC user myself, and it is difficult to predict how my customers are using (or even importing) GoJS into their LWC apps. Some may be doing it more correctly than others.

One has set me up a sandbox with two Diagrams, and so two DIVs that hold elements:

<div id="d1"> <!-- the user creates this DIV and GoJS populates its contents -->
  <canvas></canvas>
</div>

<div id="d2">  <!-- the user creates this DIV and GoJS populates its contents -->
  <canvas></canvas>
</div>

The problem is (as far as I know) only in the dragging between Divs/Canvases, which I assume is where the sandbox is failing. What I am able to confirm by inspection is that when PointerDown on one begins on one, and PointerUp ends upon the second one, the <div> and <canvas> as the event target of the second one do not have _diagram attached as a property. Is there something the customer ought to be doing differently so that these two Divs are within the same sandbox, together?

[caridy]

well, we will need a lot more info here for sure, but I have few follow up questions:

1. are you certain that the target of the event is effectively the same element? I suspect they have those two canvas on different components, and each component is using Shadow DOM, in which case, by dropping the element on another shadow will have implications in terms of what the target was, because you can't really see the actual target if it is inside another shadow. Just a hunch.
2. did this ever worked? or it is just that they can't get it to work?

[simonsarris]

1. Unfortunately I don't know a lot about their setup and from inspecting the code I don't know enough about LWS to say. I'll continue that line of inquiry with them, though depending on their setup it seems reasonable that two or more Diagrams might be in very different components on their actual app (think of a navbar with palettes to drag and drop things from, and a main Diagram as the drop target - I would assume in LWC's concept of components, these would be separate components, but maybe not.)

GoJS does work in other component frameworks, including those that use shadow DOM.

2. They claim that with Lightning Web Security turned off, it works and has worked (since at least 2019 as far as I know), but their own requirements require them to turn this security on, so they asked me for help.

[simonsarris]

It appears they are hosting GoJS Diagrams in the same component. It also appears that switching from attached properties to using a WeakMap alone does not work. The target found is now a Proxy, which of course won't be found in the map.

Unfortunately, however go.js is added to the LWC app, I cannot seem to step through the code, so it's difficult for me to gather more information.

[jdalton]

If your library running in system mode had an API like .getData(element) then if the code in the sandbox called some code called it, them the value would be unwrapped from a proxy to an element automagically.

[caridy]

@simonsarris I think at this point what we need is a way to debug this. cc @manuel-jasso

@jdalton I wonder how can go.js be running in system mode? that seems very unlikely. My hunch is that closed shadows will break go.js. @simonsarris have you tried to use two closed shadow roots and drag and drop items between them using vanilla web components maybe?

[simonsarris]

I am sorry that I do not know enough about LWC to be of much help yet in this debugging.

In terms of the GoJS code needed, here's the simplest example of a Palette (top div) that can drag its nodes onto the Diagram (bottom div). Each has an un-styled Node that is just as line of text. Live, or as plain HTML/JS:

<script src="https://gojs.net/latest/release/go.js"></script>

<body>
  <div id="myPaletteDiv" style="width: 200px; height: 80px; border: 1px solid red"></div>
  <div id="myDiagramDiv" style="width: 200px; height: 200px; border: 1px solid black"></div>
</body>
<script>
  document.addEventListener('DOMContentLoaded', () => {
    // Create a Palette for the specified DIV HTML element
    // Can be an ID string or a reference to the HTML element itself
    myPalette = new go.Palette('myPaletteDiv');
    myPalette.model = new go.GraphLinksModel([{ key: 'DragMe' }]);

    // create a Diagram to drop onto
    myDiagram = new go.Diagram('myDiagramDiv');
    myDiagram.model = new go.GraphLinksModel([{ key: 'Alpha' }]);
  });
</script>

[caridy]

@simonsarris I tried to modify the example a little bit, here is my new code:

<script src="https://gojs.net/latest/release/go.js"></script>


<body>

  <div id="myPaletteDiv"></div> 
  <div id="myDiagramDiv"></div> 

</body>
<script>
function init() {  // Create a Palette for the specified DIV HTML element
  // Can be an ID string or a reference to the HTML element itself
  const sr1 = document.querySelector("#myPaletteDiv").attachShadow({ mode: 'open' });
  sr1.innerHTML = '<div style="width:200px; height:80px; border: 1px solid red;"></div>';
  myPalette = new go.Palette(sr1.firstChild);
  myPalette.model = new go.GraphLinksModel(
    [
      { key: "DragMe" }
    ]);
  
  // create a Diagram to drop onto
  const sr2 = document.querySelector("#myDiagramDiv").attachShadow({ mode: 'open' });
  sr2.innerHTML = '<div style="width:200px; height:200px; border: 1px solid black;"></div>';
  myDiagram = new go.Diagram(sr2.firstChildElement);
  myDiagram.model = new go.GraphLinksModel(
    [
      { key: "Alpha" }
    ]);

} // end init

init();
</script>

This is pretty much the same... but this time rather than using the divs inside the body, I'm attaching an open shadow inside those divs, create new divs inside the shadows, styling them there, and creating the palette and diagram on each shadow... and it does not work. I can only drag it in the scope of the container shadow, but not beyond. I don't know if this is what they are facing... but certain raise the question about gojs working with ShadowDOM. Note: I'm using open shadow, but with LWS you get closed shadows... so that is even more complicated.