Merged
Conversation
dosubot
bot
added
the
size:XS
Contributor
📝 WalkthroughWalkthroughThe PR modifies node hit-testing in LGraphCanvas pointer event handlers (processMouseMove, processMouseDown). When Vue nodes mode is enabled, hit-testing is bypassed to delegate node interactions to Vue-based handling instead of LiteGraph's native hit-detection. Changes
Possibly related PRs
Suggested reviewers
✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🎨 Storybook Build Status✅ Build completed successfully! ⏰ Completed at: 01/18/2026, 09:12:48 AM UTC 🔗 Links🎉 Your Storybook is ready for review! |
🎭 Playwright Tests:
|
Bundle Size ReportSummary
Category Glance Per-category breakdownApp Entry Points — 18.1 kB (baseline 18.1 kB) • ⚪ 0 BMain entry bundles and manifests
Status: 1 added / 1 removed Graph Workspace — 878 kB (baseline 878 kB) • ⚪ 0 BGraph editor runtime, canvas, workflow orchestration
Status: 1 added / 1 removed Views & Navigation — 66.6 kB (baseline 66.6 kB) • ⚪ 0 BTop-level views, pages, and routed surfaces
Status: 9 added / 9 removed Panels & Settings — 385 kB (baseline 385 kB) • ⚪ 0 BConfiguration panels, inspectors, and settings screens
Status: 8 added / 8 removed User & Accounts — 4.22 kB (baseline 4.22 kB) • ⚪ 0 BAuthentication, profile, and account management bundles
Status: 3 added / 3 removed Editors & Dialogs — 2.85 kB (baseline 2.85 kB) • ⚪ 0 BModals, dialogs, drawers, and in-app editors
Status: 2 added / 2 removed UI Components — 26.3 kB (baseline 26.3 kB) • ⚪ 0 BReusable component library chunks
Status: 5 added / 5 removed Data & Services — 2.75 MB (baseline 2.75 MB) • 🔴 +32 BStores, services, APIs, and repositories
Status: 7 added / 7 removed Utilities & Hooks — 16.6 kB (baseline 16.6 kB) • ⚪ 0 BHelpers, composables, and utility bundles
Status: 4 added / 4 removed Vendor & Third-Party — 9.09 MB (baseline 9.09 MB) • ⚪ 0 BExternal libraries and shared vendor chunks
Other — 5.91 MB (baseline 5.91 MB) • ⚪ 0 BBundles that do not match a named category
Status: 25 added / 25 removed |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/lib/litegraph/src/LGraph.ts (1)
1097-1103: Guard disables node hit-testing in Vue mode.
getNodeOnPosnow always returns null whenLiteGraph.vueNodesModeis active, which can break selection/dragging/linking/hover logic that still relies on this hit-test in Vue mode. The reported bug is cursor-only at the edge; this change suppresses all node hit detection globally. Please confirm Vue mode interactions still work and consider moving the suppression toLGraphCanvas.processMouseMove(cursor decision point) or gating it to the specific edge/canvas-overlap scenario instead of blanket disabling.Run this to inspect call sites and the cursor logic:
#!/bin/bash # Find getNodeOnPos call sites and inspect processMouseMove behavior rg -n -C3 '\bgetNodeOnPos\b' src/lib/litegraph rg -n -C3 '\bprocessMouseMove\b' src/lib/litegraph/src/LGraphCanvas.ts
Collaborator
Author
|
PR causes a regression with requiring a draggedlink to be directly over a vue node to connect instead of just being near to one. |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/lib/litegraph/src/LGraphCanvas.ts`:
- Around line 3190-3193: The current change in LGraphCanvas (where node is set
to null when LiteGraph.vueNodesMode is true) disables hit-testing and breaks
link-snapping; instead, call graph.getNodeOnPos(x, y, this.visible_nodes) in all
modes (so processMouseMove still receives a node) but when Vue mode is active
suppress the cursor/hover logic by masking out CanvasItem.Node (i.e., gate the
cursor crosshair/hover checks in processMouseMove by checking
LiteGraph.vueNodesMode before using the CanvasItem.Node flag); return undefined
rather than null to follow litegraph conventions and ensure no other code treats
the value as a deliberate null.
Comment on lines
+3190
to
3193
| const node = LiteGraph.vueNodesMode | ||
| ? null | ||
| : graph.getNodeOnPos(x, y, this.visible_nodes) | ||
|
|
Contributor
There was a problem hiding this comment.
Regression risk: disabling node hit-testing breaks link snapping in Vue mode.
Setting node to null in Vue mode bypasses all slot/hover/link highlight logic in processMouseMove, which matches the reported regression where dragged links only connect when directly over the node. Keep hit-testing, and instead suppress the cursor crosshair by gating the CanvasItem.Node flag. Also prefer undefined over null for litegraph internals.
✅ Suggested fix (preserve hit-testing, suppress cursor)
- const node = LiteGraph.vueNodesMode
- ? null
- : graph.getNodeOnPos(x, y, this.visible_nodes)
+ const node = graph.getNodeOnPos(x, y, this.visible_nodes) ?? undefined
+ const allowNodeHover = !LiteGraph.vueNodesMode
@@
- if (node) {
- underPointer |= CanvasItem.Node
+ if (node) {
+ if (allowNodeHover) underPointer |= CanvasItem.NodeAs per coding guidelines, prefer returning undefined over null in litegraph code.
🤖 Prompt for AI Agents
In `@src/lib/litegraph/src/LGraphCanvas.ts` around lines 3190 - 3193, The current
change in LGraphCanvas (where node is set to null when LiteGraph.vueNodesMode is
true) disables hit-testing and breaks link-snapping; instead, call
graph.getNodeOnPos(x, y, this.visible_nodes) in all modes (so processMouseMove
still receives a node) but when Vue mode is active suppress the cursor/hover
logic by masking out CanvasItem.Node (i.e., gate the cursor crosshair/hover
checks in processMouseMove by checking LiteGraph.vueNodesMode before using the
CanvasItem.Node flag); return undefined rather than null to follow litegraph
conventions and ensure no other code treats the value as a deliberate null.
christian-byrne
approved these changes
Jan 18, 2026
godwiniheuwa
pushed a commit
to godwiniheuwa/ComfyUI_frontend
that referenced
this pull request
Jan 22, 2026
When the mouse cursor is at the very edge of a a node in vue mode, a crosshair cursor will sometimes display. This happens because the mouse is over the canvas, and `LGraphCanvas.processMouseMove` determines the cursor is still above the node. ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-8120-Fix-crosshair-cursor-in-vue-mode-2eb6d73d36508116a3cfdd407c5e1e9c) by [Unito](https://www.unito.io) --------- Co-authored-by: Alexander Brown <drjkl@comfy.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the mouse cursor is at the very edge of a a node in vue mode, a crosshair cursor will sometimes display. This happens because the mouse is over the canvas, and
LGraphCanvas.processMouseMovedetermines the cursor is still above the node.This fix feels kinda ick. I don't believe that we can trust thegetNodeOnPoscall to be accurate when in vue mode, but this change could likely have side effects. Perhaps the check should be performed inprocessMouseMoveinstead?┆Issue is synchronized with this Notion page by Unito