Using foreignObject "steals" all Node events (onEnter, etc.) - How to forward events when using foreignObject?

[Vadorequest]

I'm submitting a...

[x] Other

Current behavior

I'm confused about how foreignObjects are meant to be used. The issue I noticed is foreignObject appear on top of the rect and thus "steals" all events assigned to the rect.

In practice, this means our nodes cannot benefit from the native features such as dragging and creating connections. Also, stuff like focusing/selecting doesn't apply either. (because we're targeting the foreignObject, not the rect)

It's reproductible with the Storybook demo
https://reaflow.dev/?path=/story/demos-nodes--foreign-objects

So, how are we supposed to forward events (onEnter, etc.) from our Node to the underlying foreignObject child?

Events such as onClick can be applied to foreignObject easily, but other like onEnter/onLeave cannot.

Expected behavior

This might be a feature request, or a documentation issue. But how should we make our nodes behave properly when using a foreignObject as children? Ideally, we should still be able to draw connections when using foreignObject.

Also, this is particularly impactful for drag and drop, because onEnter/onLeave can't be used.

Repro

https://reaflow.dev/?path=/story/demos-nodes--foreign-objects

Because foreignObject is being used, it's not possible to create a connection from a node.
When modifying the DOM directly, (inverting react and foreignObject) it's then possible to receive onEnter/onLeave events, but the foreignObject is hidden behind.

Ideas

One way to go around this issue is to have the rect appear on top (after in DOM) of the foreignObject, but make it unclickable (point-events:none or opacity:1) maybe?

[amcdnl]

I would change your pointer events in CSS to act appropriately. Someone else has brought this up and it worked for them.

PS - Questions are usually best handled in discussions vs issues.

[Vadorequest]

Indeed, I wasn't sure if it was a question or feature request.

Related discussion: #34

I'll try out pointer-events then. Thanks for the feedback!