Fix clicks near DOMWidgets being swallowed

[AustinMroz]

DOMWidgets do not perfectly align with their allocated space on a node.
Clicks on the element proper are never seen by litegraph, but there's a small border region where the LegacyWidget onClick method is called (See LGraphNode.getWidgetOnPos). To end users who will not see the console warning, it appears the click just gets swallowed.

This PR addresses the issue in two parts:

• It provides a method on canvas to set a pointer event to be handled as a passthrough
• It sets DOMWidgets to use this method for clicks that are not handled by the element itself

┆Issue is synchronized with this Notion page by Unito

[github-actions]

🎭 Playwright Test Results

✅ All tests passed across all browsers!

⏰ Completed at: 08/31/2025, 03:48:01 AM UTC

📊 Test Reports by Browser

---

🎉 Your tests are passing across all browsers!

[DrJKL]

Any chance this could be clobbering something?

[DrJKL]

If it's an intentional mutation, I usually like to note that in the function name.
Something like augmentPointerDragEvents maybe?

[DrJKL]

Complete side-note, what does the return boolean indicate?

[AustinMroz]

It indicates that the pointer event is handled and no more processing should be performed. Here, it just skips a bunch of legacy mouse event handling code and prevents a warning message from being printed in the console about the legacy code.

[DrJKL]

So it kind of emulates preventDefault or cancel on a true event?

[DrJKL]

It feels weird to add listeners as a result of a different event here.

[christian-byrne]

Not to say this change is not good in its own right, but I wonder if there's also a bonafide bug/regression in the hit-testing? (Or maybe the cause is stated elsewhere and I am missing it -- apologies if so.)

It seems this line is using 6px:

ComfyUI_frontend/src/lib/litegraph/src/LGraphNode.ts

Lines 2140 to 2143 in c3c2681

	if (
	widget.last_y !== undefined &&
	isInRectangle(x, y, 6, widget.last_y, w - 12, h)
	) {

Would the issue be solved by doing something like this:

getWidgetOnPos(canvasX: number, canvasY: number, includeDisabled = false): IBaseWidget | undefined {
  // ... existing code ...

  for (const widget of widgets) {
    // ... visibility checks ...

    // Use DOM widget margin instead of hardcoded 6px
    const margin = widget.margin ?? 6  // DOM widgets have margin property
    
    // ... other code ..

    if (
      widget.last_y !== undefined &&
      isInRectangle(x, y, margin, widget.last_y, w - margin * 2, h)  
    ) {
      return widget
    }
  }
}

[AustinMroz]

Will do some testing. I would also prefer this as I'm not completely confident about custom nodes using both domWidget + legacy mouse method. Code search was inconclusive.

IIRC, the space between widgets will always be assigned to a widget, but the primary annoyance was clicks above the first widget.

[AustinMroz]

After investigating, this works much better than expected.

• The margin attribute on DOMwidgets works fabulously, The widget fills last_y + margin to h - 2*margin cleanly
• Normal widgets have 4 pixels height margin, but an inconvenient height offset.
  • Since the gap between widgets is small, it may be worth fixing the height offset, but setting margins to 0 for QOL: No one wants to select or drag a node by clicking between normal widgets.

[webfiltered]

• No one wants to select or drag a node by clicking between normal widgets.

The removal of gap between widgets was intentional; it always felt like it was a bug to me.

The glitchy feeling of it intensified when we added "drag link on widget => auto-convert to input" - caused flickering when you dragged a link over a node. After I added snap highlighting on the widgets, it -really- needed to go.

[github-actions]

🎨 Storybook Build Status

❌ Build failed!

⏰ Completed at: 08/31/2025, 03:24:52 AM UTC

🔗 Links

• 📊 View Workflow Run

---

⚠️ Please check the workflow logs for error details.

[christian-byrne]

LGTM!