## Summary
- Add `contextMenuConverter.ts` with utilities for converting LiteGraph
context menu items to Vue menu format
- Improve `contextMenuCompat.ts` with set-based diffing for more
reliable legacy extension detection
- Extend `MenuOption`/`SubMenuOption` types with `source`, `disabled`,
`isColorPicker`, and `category` type fields
- Add unit tests for converter functions
## Context
This is foundational work for migrating the node context menu from a
custom Popover-based component to PrimeVue ContextMenu.
The converter provides:
- Menu ordering and section grouping (core items first, then extensions)
- Deduplication with preference for Vue-native items over LiteGraph
items
- Extension categorization with labeled section
- Support for disabled states and color picker submenus
## Test plan
- [x] Unit tests pass for `buildStructuredMenu` (9 tests)
- [x] Unit tests pass for `convertContextMenuToOptions` (7 tests)
- [x] Typecheck passes
- [x] Lint passes
- [x] Knip passes (no unused exports)
## Related
This is PR 1 of 2 for the node context menu migration. PR 2 will wire up
the UI component.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7113-feat-Add-context-menu-converter-infrastructure-2be6d73d3650816ca6c9d2cf50f10159)
by [Unito](https://www.unito.io)
## Summary
Fixes the issue where unpacking a subgraph containing missing nodes
causes those nodes to disappear. Missing nodes are now automatically
restored as placeholder nodes that preserve their original data,
allowing them to be recovered when the node types are installed later.
## Changes
- **What**:
- Modified `multiClone()` to preserve missing nodes as serialized data
when creating subgraphs
- Added `skipMissingNodes` option to `unpackSubgraph()` method to
restore missing nodes as placeholder nodes instead of throwing errors
- Updated `useSubgraphOperations.unpackSubgraph()` to automatically
restore missing nodes as placeholders (removed confirmation dialog)
- Replaced deprecated `LiteGraph.cloneObject()` with `structuredClone()`
- Removed unused i18n keys and debugging logs
## Review Focus
- **Placeholder node restoration**: Missing nodes are restored using the
same mechanism as `LGraph.configure()` (creating `LGraphNode` with
`last_serialization` and `has_errors` flags). This ensures compatibility
with the existing missing node manager.
- **Performance**: Optimized `getMissingNodeTypes()` to check
`registered_node_types` first before attempting node creation, and uses
Set for O(1) duplicate checking.
- **Data preservation**: Missing nodes preserve their original type,
title, and serialized data in `last_serialization`, allowing automatic
recovery when node types are installed.
- **Backward compatibility**: The `skipMissingNodes` option defaults to
`false`, maintaining original behavior for other code paths. Only the
UI-level `unpackSubgraph()` always uses `skipMissingNodes: true`.
<!-- If this PR fixes an issue, uncomment and update the line below -->
<!-- Fixes#7279 -->
## Demo
Before:
https://github.com/user-attachments/assets/e0327d05-802d-4a64-a9db-4d174e185d82
After:
https://github.com/user-attachments/assets/37ab3140-0ada-480e-b9d5-fef8856f8b27
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7341-fix-unpacking-a-missing-node-causes-it-to-disappear-2c66d73d36508151ac6be70a7b2bc56d)
by [Unito](https://www.unito.io)
## Summary
Changes the layout store to treat node sizes as body-only measurements
while LiteGraph continues to reason about full heights. DOM-driven
updates are tagged with `LayoutSource.DOM`, which lets the store strip
the title height exactly once before persisting. That classification (a
new mutation source - `LayoutSource.DOM`) is accurate because those
mutations are triggered by the browser’s layout engine via
ResizeObserver, rather than by direct calls into the layout APIs (e.g.,
`moveNodeTo`, `useNodeDrag`). So all sources are:
- `LayoutSource.DOM`: browser layout/ResizeObserver measurements that
include the title bar
- `LayoutSource.Vue`: direct Vue-driven mutations routed through the
layout store
- `LayoutSource.Canvas`: legacy LiteGraph/canvas updates that will be
phased out over time
- `LayoutSource.External`: for multiplayer or syncing with a when going
online after making changes offline (in teams/workspace)
When layout state flows back into LiteGraph we add the title height just
in time for `liteNode.setSize`, so LiteGraph’s rendering stays
unchanged. This makes Vue node resizing and workflow persistence
deterministic - multiline widgets hold their dimensions across reloads
because every path that crosses the layout/LiteGraph boundary performs
the same normalization.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6966-normalize-height-at-sites-2b76d73d365081b6bcb4f4ce6a27663a)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
**Problem:** ensureCorrectLayoutScale scales up LG -> Vue. But doesn't
scale down from Vue -> LG.
**Solution:** Bi directional scaling.
**Bonus:** fix edge cases such as subgraphs, groups, and reroutes. Also,
set auto scale: true now that we 'preserve' LG scale.
**IMPORTANT:** useVueNodeResizeTracking.ts sets vue node height -
Litegraph.NODE_TITLE_HEIGHT on workflow load using a resize observer.
Reloading the page (loading a workflow) in Vue mode, will subtract
height each time. This can look like a problem caused by
ensureCorrectLayoutScale. It is not. Need to fix. Here was an attempt by
[removing the Litegraph.NODE_TITLE_HEIGHT
entirely](https://github.com/Comfy-Org/ComfyUI_frontend/pull/6643).
## Review Focus
Full lifecycle of loading workflows and switching between vue and lg.
Race conditions could be present. For example switching the mode using
keybind very fast.
## Screenshots (if applicable)
https://github.com/user-attachments/assets/5576b760-13a8-45b9-b8f7-64e1caf443c1https://github.com/user-attachments/assets/46d6f870-df76-4084-968a-53cb629fc123
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
- Adds [Oxc linter](https://oxc.rs/docs/guide/usage/linter) as a dev
dependency
- Creates minimal `.oxlintrc.json` configuration file
- Integrates oxlint into the lint workflow (runs before ESLint)
- Adds `pnpm oxlint` script for standalone usage
- **NEW**: Adds
[eslint-plugin-oxlint](https://github.com/oxc-project/eslint-plugin-oxlint)
to disable redundant ESLint rules
- Updates `CLAUDE.md` documentation with oxlint command
## Motivation
Oxc is a high-performance Rust-based linter that is 50-100x faster than
ESLint. By integrating it into our lint workflow, we get:
- **Faster CI/CD pipelines** (5% improvement in this codebase)
- **Quicker local development feedback**
- **Additional code quality checks** that complement ESLint
- **Reduced duplicate work** by disabling ESLint rules that oxlint
already checks
## Changes
- **package.json**: Added `oxlint` and `eslint-plugin-oxlint` to
devDependencies, integrated into `lint`, `lint:fix`, and `lint:no-cache`
scripts
- **pnpm-workspace.yaml**: Added `eslint-plugin-oxlint` and
`mixpanel-browser` to catalog
- **eslint.config.ts**: Integrated `eslint-plugin-oxlint` to
automatically disable redundant ESLint rules
- **.oxlintrc.json**: Created minimal configuration file with schema
reference
- **CLAUDE.md**: Added `pnpm oxlint` to Quick Commands section
- **.gitignore**: Added `core` dump files
## CI/CD Performance Benchmark
Real-world CI/CD timing from GitHub Actions workflow runs:
### Baseline (ESLint only) - [Run
#18718911051](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18718911051)
- Run ESLint with auto-fix: **125s**
- Final validation (lint + format + knip): **16s**
- **Total: 141s**
### With Oxlint (oxlint + ESLint) - [Run
#18719037963](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18719037963)
- Run ESLint with auto-fix (includes oxlint): **118s**
- Final validation (includes oxlint + lint + format + knip): **16s**
- **Total: 134s**
### Results
✅ **7 seconds faster (5.0% improvement)** despite running an additional
linting pass
### Analysis
The oxlint integration actually **improves** CI/CD performance by ~5%.
This unexpected improvement is likely because:
1. **Oxlint catches issues early**: Some code that would have slowed
down ESLint's parsing/analysis is caught by oxlint first
2. **ESLint cache benefits**: The workflow uses `--cache`, and oxlint's
fast execution helps populate/validate the cache more efficiently
3. **Parallel processing**: Modern CI runners can overlap some of the
I/O operations between oxlint and ESLint
Even if oxlint added overhead, the value proposition would still be
strong given its additional code quality checks and local development
speed benefits. The fact that it actually speeds up the pipeline is a
bonus.
## eslint-plugin-oxlint Performance Impact
Benchmark comparing ESLint performance with and without
eslint-plugin-oxlint:
### Baseline (ESLint without plugin) - [Run
#18723242157](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723242157)
- Run ESLint with auto-fix: **122s** (2m 2s)
- Final validation: **17s**
### With eslint-plugin-oxlint - [Run
#18723675903](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723675903)
- Run ESLint with auto-fix: **129s** (2m 9s)
- Final validation: **12s**
### Results
**Performance: +7 seconds ESLint, -5 seconds validation (net +2
seconds)**
The eslint-plugin-oxlint integration has a **minimal performance
impact** (+2 seconds total). The slight increase in ESLint time is
likely due to the additional plugin configuration overhead, while the
validation step is faster because fewer redundant lint warnings need to
be processed.
### Benefits
The small performance cost is outweighed by important benefits:
1. **Prevents duplicate work**: Disables ~50 ESLint rules that oxlint
already checks (e.g., `no-constant-condition`, `no-debugger`,
`no-empty`, etc.)
2. **Reduces noise**: Eliminates redundant lint warnings from two tools
checking the same thing
3. **Cleaner workflow**: One authoritative source for each type of lint
check
4. **Best practice**: Recommended by the Oxc project for ESLint + oxlint
integration
5. **Consistent results**: Ensures both tools don't conflict or give
contradictory advice
## Usage
```bash
# Run oxlint standalone
pnpm oxlint
# Run full lint workflow (oxlint + ESLint)
pnpm lint
pnpm lint:fix
```
## Notes
- Oxlint now runs as part of the standard `pnpm lint` workflow
- The configuration uses minimal rules by default (Oxc's philosophy is
"catch erroneous or useless code without requiring any configurations by
default")
- Oxlint provides fast feedback while ESLint provides comprehensive
checks
- eslint-plugin-oxlint automatically manages rule conflicts between the
two tools
- Both tools complement each other in the linting pipeline
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6197-chore-Add-Oxc-linter-to-project-2946d73d3650818cbb55ef9c0abdb9b9)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: DrJKL <DrJKL0424@gmail.com>
This pull request introduces several improvements to Vue reactivity and
user experience in the graph node and widget system. The main focus is
on ensuring that changes to node and widget data reliably trigger
updates in Vue components, improving drag-and-drop support for nodes,
and enhancing widget value handling for better compatibility and
reactivity.
**Vue Reactivity Improvements:**
* In `useGraphNodeManager.ts`, node data updates now create a completely
new object and add a timestamp (`_updateTs`) to force Vue's reactivity
system to detect changes. Additionally, node data is re-set on the next
tick to guarantee component updates.
[[1]](diffhunk://#diff-f980db6f42cef913c3fe92669783b255d617e40b9ccef9a1ab9cc8e326ff1790L272-R280)
[[2]](diffhunk://#diff-f980db6f42cef913c3fe92669783b255d617e40b9ccef9a1ab9cc8e326ff1790R326-R335)
* Widget value composables (`useWidgetValue` and related helpers) now
accept either a direct value or a getter function for `modelValue`, and
always normalize it to a getter. Watches are updated to use this getter
for more reliable reactivity.
[[1]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911L13-R14)
[[2]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911R49-R57)
[[3]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911L82-R91)
[[4]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911L100-R104)
[[5]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911L117-R121)
[[6]](diffhunk://#diff-92dc3c8b09ab57105e400e115196aae645214f305685044f62edc3338afa0911L140-R144)
[[7]](diffhunk://#diff-0c43cefa9fb524ae86541c7ca851e97a22b3fd01f95795c83273c977be77468fL47-R47)
* In `useImageUploadWidget.ts`, widget value updates now use a new
array/object to ensure Vue detects the change, especially for batch
uploads.
**Drag-and-Drop Support for Nodes:**
* The `LGraphNode.vue` component adds drag-and-drop event handlers
(`dragover`, `dragleave`, `drop`) and visual feedback (`isDraggingOver`
state and highlight ring) for improved user experience when dragging
files onto nodes. Node callbacks (`onDragOver`, `onDragDrop`) are used
for custom validation and handling.
[[1]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2L26-R27)
[[2]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R47-R49)
[[3]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R482-R521)
**Widget and Audio Upload Handling:**
* In `uploadAudio.ts`, after uploading an audio file, the widget's
callback is manually triggered to ensure Vue nodes update. There is also
a commented-out call to mark the canvas as dirty for potential future
refresh logic.
[[1]](diffhunk://#diff-796b36f2cafb906a5e95b5750ca5ddc1bf57a304d4a022e0bdaee04b4ee5bbc4R61-R65)
[[2]](diffhunk://#diff-796b36f2cafb906a5e95b5750ca5ddc1bf57a304d4a022e0bdaee04b4ee5bbc4R190-R191)
These changes collectively improve the reliability and responsiveness of
UI updates in the graph node system, especially in scenarios involving
external updates, drag-and-drop interactions, and batch widget value
changes.
https://github.com/user-attachments/assets/8e3194c9-196c-4e13-ad0b-a32177f2d062
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6514-Drag-vuenodes-input-29e6d73d3650817da1b7ef96b61b752d)
by [Unito](https://www.unito.io)
## Summary
### Problem:
The Vue nodes renderer/feature introduces new designs for each node i.e.
the equivalent Litegraph node design is smaller and the vue node design
is non uniformly larger.
### Example:
Litegraph Ksampler node: 200w x 220h
<img width="200" height="220" alt="image"
src="https://github.com/user-attachments/assets/eef0117b-7e02-407d-98ab-c610fd1ec54c"
/>
Vue Node Ksampler node: 445w x 430h
<img width="445" height="430" alt="image"
src="https://github.com/user-attachments/assets/e78d9d45-5b32-4e8d-bf1c-bce1c699037f"
/>
This means if users load a workflow in Litegraph and then switches to
Vue nodes renderer the nodes are using the same Litegraph positions
which would cause a visual overlap and overall look broken.
### Example:
<img width="1510" height="726" alt="image"
src="https://github.com/user-attachments/assets/3b7ae9d2-6057-49b2-968e-c531a969fac4"
/>
<img width="1475" height="850" alt="image"
src="https://github.com/user-attachments/assets/ea10f361-09bd-4daa-97f1-6b45b5dde389"
/>
### Solution:
Scale the positions of the nodes in lite graph radially from the center
of the bounds of all nodes. And then simply move the Vue nodes to those
new positions.
1. Get the `center of the bounds of all LG nodes`.
2. Get the `xy of each LG node`.
3. Get the vector from `center of the bounds of all LG nodes` `-` `xy of
each LG node`.
4. Scale it by a factor (e.g. 1.75x which is the average Vue node size
increase plus some visual padding.)
5. Move each Vue node to the scaled `xy of each LG node`.
Result: The nodes are spaced apart removing overlaps while keeping the
spatial layout intact.
<img width="2173" height="1096" alt="image"
src="https://github.com/user-attachments/assets/7817d866-4051-47bb-a589-69ca77a0bfd3"
/>
### Further concerns.
This vector scaling algorithm needs to run once per workflow when in vue
nodes. This means when in Litegraph and switching to Vue nodes, it needs
to run before the nodes render. And then now that the entire app is in
vue nodes, we need to run it each time we load a workflow. However, once
its run, we do not need to run it again. Therefore we must persist a
flag that it has run somewhere. This PR also adds that feature by
leveraging the `extra` field in the workflow schema.
---------
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: JakeSchroeder <jake@axiom.co>
## Summary
The private fields triggered an error in intitializing the
linkLayoutSync. Turns out that wasn't necessary anymore.
> [!NOTE]
> Edit: Doing some more investigation, it looks like the slot sync can
also be removed?
## Changes
- **What**: Converts JS private fields to typescript private, adds some
readonly declarations
- **What**: Removes the useLinkLayoutSync usage in useVueNodeLifecycle
- **What**: Removes the useSlotLayoutSync usage in useVueNodeLifecycle
## Review Focus
Was the sync doing something that wouldn't be caught in normal
usage/testing?
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6330-Fix-Vue-Litegraph-conversion-bug-with-Reroutes-2996d73d3650819ebb24e4aa2fc51c65)
by [Unito](https://www.unito.io)
Makes the litegraph `node.widgets` array `shallowReactive` and makes the
`nodeData.widgets` a `reactiveComputed` derived from the litegraph
widget data.
Making changes to the structure of litegraph items is somewhat
dangerous, but code search verifies that there are no custom nodes using
`defineProperty` on `node.widgets`
This fixes display of promoted widgets on subgraph node and any custom
nodes that dynamically add or remove widgets.
TODO:
- Investigate occasional dropped widgets.
- Some of this was confusion with `canvasOnly` widgets and widgets not
implemented in vue. Will keep investigating, but I'm not terribly
concerned with actual test cases and it being an objective improvement.
Known Issue:
- Node does not grow/shrink to fit changed widgets
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6019-Make-nodeData-widgets-reactive-2896d73d3650815691b6ee370a86a22c)
by [Unito](https://www.unito.io)
Did testing on about a dozen custom nodes. Most just work.
- Some custom nodes have copy/pasted the `addDOMWidget` call with types
like `customtext` and get converted to textareas -> Not feasible to fix
here. Can open PRs into custom nodes if complaints arise.
- Only the KJNodes spline editor had mouse issues -> Can
investigate/open PR into KJNodes later.
- Many nodes don't resize gracefully. Probably best handled in a future
PR.
- Some expect to be handled like textareas. These currently have minsize
and don't scale.
- Others, like VHS previews, scale self properly, but don't update
height inside a drag operation -> node height can be set to less than
fit.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6006-Implement-DOMWidget-for-vue-2886d73d3650817ca497c15d87d70f4f)
by [Unito](https://www.unito.io)
## Summary
Fixes https://github.com/Comfy-Org/ComfyUI_frontend/issues/5692 by
making widget link connection status trigger on change so Vue widgets
with connected links could properly switch to the `disabled` state when
they are implicitly converted to inputs.
## Changes
- **What**: Added `node:slot-links:changed` event tracking and reactive
slot data synchronization for Vue widgets
```mermaid
graph TD
A[Widget Link Change] --> B[NodeInputSlot.link setter]
B --> C{Is Widget Input?}
C -->|Yes| D[Trigger slot-links:changed]
C -->|No| E[End]
D --> F[Graph Event Handler]
F --> G[syncNodeSlotData]
G --> H[Update Vue Reactive Data]
H --> I[Widget Re-render]
style A fill:#f9f9f9,stroke:#333,color:#000
style I fill:#f9f9f9,stroke:#333,color:#000
```
## Review Focus
Widget reactivity performance with frequent link changes and event
handler memory management in graph operations.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5834-fix-Vue-node-widgets-should-be-in-disabled-state-if-their-slots-are-connected-with-a-link-27c6d73d365081f6a6c3c1ddc3905c5e)
by [Unito](https://www.unito.io)
## Summary
Added `canvasOnly` flag to runtime-generated widgets to prevent Vue
renderer from displaying them while keeping canvas functionality intact.
## Changes
- **What**: Added `canvasOnly` widget option to hide upload, webcam, and
refresh widgets from Vue renderer
In the Canvas (LiteGraph) system, there was a small set of widgets with
strictly defined components. There, if we wanted some unique or
relatively complex behavior (like an upload butotn), we needed to create
a separate widget that would be coupled to the original widget at
runtime (and would not be serialized).
In the Vue renderer system, we can simply add flags to the inputSpec or
widget options and conditionally render complex UI additions -- i.e.,
there is no need for the hard-to-maintain runtime widget associations.
Expressing such things entirely in the view layer simplifies business
logic related to graph state, as we no longer need to account for
preserving the connections between runtime widgets and their special
siblings -- we also do not need to worry about the implications for
state serialization.
## Related
- https://github.com/Comfy-Org/ComfyUI_frontend/pull/5798
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5831-designate-canvasOnly-on-runtime-generated-virtual-widgets-so-they-are-hidden-in-Vue-ren-27c6d73d365081fb8641feec010190df)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
Cleanup and fixes to the existing syncing logic.
## Review Focus
This is probably enough to review and test now.
Main things that should still work:
- moving nodes around
- adding new ones
- switching back and forth between Vue and Litegraph
Let me know if you find any bugs that weren't already present there.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5789-WIP-Litegraph-Vue-synchronization-work-27a6d73d3650811682cacacb82367b9e)
by [Unito](https://www.unito.io)
This pull request refactors and improves the "More Options" popover
functionality for graph nodes in the UI. The main change is a rename and
redesign of the menu component from `MoreOptions` to `NodeOptions`,
introducing a global singleton pattern for popover control and enabling
context menu support on node right-click. This results in better
maintainability, more flexible triggering, and improved user experience.
**Node Options popover refactor and global control:**
* Renamed and refactored `MoreOptions.vue` to `NodeOptions.vue`,
removing the embedded button and exposing imperative methods (`toggle`,
`hide`, `isOpen`) for external control. The component now
registers/unregisters itself globally via `registerNodeOptionsInstance`.
[[1]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL2-R2)
[[2]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL203-R197)
[[3]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eR294-R309)
* Added `NodeOptionsButton.vue` as a dedicated button component for
triggering the popover, decoupling the button UI from the popover logic.
* Implemented a global singleton pattern in `useMoreOptionsMenu.ts` for
controlling the `NodeOptions` popover from anywhere, with
`toggleNodeOptions` and `registerNodeOptionsInstance` functions.
[[1]](diffhunk://#diff-ae87bdb1e06725eb19b8d0fc82ec40a5f8ca831a6632767cc5d214fc903b89b6R35-R65)
[[2]](diffhunk://#diff-ae87bdb1e06725eb19b8d0fc82ec40a5f8ca831a6632767cc5d214fc903b89b6L184-R216)
**UI integration and event handling improvements:**
* Updated `SelectionToolbox.vue` to use the new `NodeOptionsButton`
instead of the previous embedded `MoreOptions` button, and added the
`NodeOptions` popover to the main `GraphCanvas.vue` template for global
accessibility.
[[1]](diffhunk://#diff-05d80ee1e28e634dc758394ddf1bfaa8e5ec72a186a6ea2e2b6f5dfba867b264L41-R41)
[[2]](diffhunk://#diff-05d80ee1e28e634dc758394ddf1bfaa8e5ec72a186a6ea2e2b6f5dfba867b264L71-R71)
[[3]](diffhunk://#diff-aaf17c713f29c6db8ea03efe7fc3483a858982e818a324b23cff89859e71559cR65)
[[4]](diffhunk://#diff-aaf17c713f29c6db8ea03efe7fc3483a858982e818a324b23cff89859e71559cR91)
* Added right-click context menu support to `LGraphNode.vue`, triggering
the node options popover at the cursor position and integrating with
node selection logic.
[[1]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R45)
[[2]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R141)
[[3]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2L180-R187)
[[4]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R249-R263)
**Minor improvements and cleanup:**
* Updated references and variable names throughout the codebase to
reflect the new `NodeOptions` naming and logic.
[[1]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL53)
[[2]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eR50)
[[3]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL75-R60)
[[4]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL91-L95)
[[5]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL110-R90)
[[6]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL133-R113)
[[7]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL146-R126)
[[8]](diffhunk://#diff-e0dbd5e37efd2c79e7317415455340b0dd150b758077b170a663f67d2453605eL157-R140)
This refactor makes the node options menu more modular, easier to
maintain, and more flexible for future UI improvements.
https://github.com/user-attachments/assets/9c2f2556-4544-4e20-9f22-8f485b0ceadc
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5790-Right-click-vue-nodes-27a6d73d365081a98263c88d2e09e629)
by [Unito](https://www.unito.io)
## Summary
I want to take a more general look at `comfyApp.graph.onTrigger` but
this is the cleanest fix I could come up with for #5694.
I will explore simplifying onTrigger in a separate PR.
## Changes
1. Create a `node:slot-errors:changed` trigger.
2. Trigger it if we find any of the node slots have errors.
3. Check each node to see if there is any error present.
4. Add an error class if there are.
## Screenshots (if applicable)
Working error states!
<img width="1049" height="987" alt="Screenshot 2025-09-23 at 8 40 04 PM"
src="https://github.com/user-attachments/assets/30e13283-129c-4d9c-b342-e7037582998a"
/>
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5758-fix-properly-show-error-states-2786d73d365081cbbf62c314c7f5f380)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Alexander Brown <drjkl@comfy.org>
## Summary
Prerequisite refactor/cleanup to use a global store instead of having
nodes throw up events to a parent component that stores a reference to a
singleton service that itself bootstraps and synchronizes with a
separate service to maintain a partially reactive but not fully reactive
set of states that describe some but not all aspects of the nodes on
either the litegraph, the vue side, or both.
## Changes
- **What**: Refactoring, the behavior should not change.
- **Dependencies**: A type utility to help with Vue component props
## Review Focus
Is there something about the current structure that this could affect
that would not be caught by our tests or using the application?
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5695-Refactor-Composable-disentangling-2746d73d365081e6938ce656932f3e36)
by [Unito](https://www.unito.io)
## Summary
Integrated Vue node components with canvas panning mode to prevent UI
interference during navigation.
## Changes
- **What**: Added
[canCapturePointerEvents](https://docs.comfy.org/guide/vue-nodes)
computed property to `useCanvasInteractions` composable that checks
canvas read-only state
- **What**: Modified Vue node components (LGraphNode, NodeWidgets) to
conditionally handle pointer events based on canvas navigation mode
- **What**: Updated node event handlers to respect panning mode and
forward events to canvas when appropriate
## Review Focus
Event forwarding logic in panning mode and pointer event capture state
management across Vue node hierarchy.
```mermaid
graph TD
A[User Interaction] --> B{Canvas in Panning Mode?}
B -->|Yes| C[Forward to Canvas]
B -->|No| D[Handle in Vue Component]
C --> E[Canvas Navigation]
D --> F[Node Selection/Widget Interaction]
G[canCapturePointerEvents] --> H{read_only === false}
H -->|Yes| I[Allow Vue Events]
H -->|No| J[Block Vue Events]
style A fill:#f9f9f9,stroke:#333,color:#000
style E fill:#f9f9f9,stroke:#333,color:#000
style F fill:#f9f9f9,stroke:#333,color:#000
style I fill:#e1f5fe,stroke:#01579b,color:#000
style J fill:#ffebee,stroke:#c62828,color:#000
```
## Screenshots
https://github.com/user-attachments/assets/00dc5e4a-2b56-43be-b92e-eaf511e52542
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5574-Make-Vue-nodes-read-only-when-in-panning-mode-26f6d73d3650818c951cd82c8fe58972)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
* [refactor] Move update-related functionality to platform/updates domain
Reorganizes release management, version compatibility, and notification functionality
following Domain-Driven Design principles, mirroring VSCode's architecture pattern.
- Move releaseService.ts to platform/updates/common/
- Move releaseStore.ts to platform/updates/common/
- Move versionCompatibilityStore.ts to platform/updates/common/
- Move useFrontendVersionMismatchWarning.ts to platform/updates/common/
- Move toastStore.ts to platform/updates/common/
- Move ReleaseNotificationToast.vue to platform/updates/components/
- Move WhatsNewPopup.vue to platform/updates/components/
- Update 25+ import paths across codebase and tests
This creates a cohesive "updates" domain containing all functionality related to
software updates, version checking, release notifications, and user communication
about application state changes.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix imports
---------
Co-authored-by: Claude <noreply@anthropic.com>
