- Add capture:true to removeEventListener calls that were added with capture
to prevent event listener leaks when unbinding
- Reuse existing target variable in Delete/Backspace check instead of
re-accessing e.target with @ts-expect-error
- Add isContentEditable check to Delete/Backspace guard for consistency
Broaden the target guard in processKey to skip all text-editable surfaces
(input, textarea, contenteditable) before handling shortcuts. This prevents
space/Ctrl+A/C from being blocked when typing in prompt textareas or other
multiline fields in Vue nodes mode.
Remove the LiteGraph.vueNodesMode check when removing the document-level
keydown listener in unbindEvents. If vueNodesMode was true during bindEvents
but changed before unbindEvents, the listener would be left dangling.
Now guarded only by existence of _key_callback.
Remove duplicate panning state management from useSlotLinkInteraction.
Instead of Vue manually manipulating canvas.ds.offset, sync pointer.isDown
with litegraph and let events bubble when in panning mode (read_only).
- Remove isPanningDuringLinkDrag and lastPanningMouse local state
- Remove manual offset manipulation in handlePointerMove
- Conditionally stopPropagation only when NOT in panning mode
- Set canvas.pointer.isDown so spacebar triggers litegraph panning
Move spacebar detection to document-level listener in LGraphCanvas when
vueNodesMode is enabled. Implement direct panning in useSlotLinkInteraction
when spacebar is held during connection drag, bypassing litegraph event
handling for smoother panning while maintaining link position updates.
Fixes#7806
## Summary
Refactored BrushSettingsPanel layout to stack labels and number inputs
above sliders, and fixed brush size keybinding limits to match the
updated 1-250 range.
## Changes
- **What**:
- Reorganized BrushSettingsPanel UI to display labels and number inputs
in a row above each slider (instead of side-by-side), creating a cleaner
vertical layout with better visual hierarchy.
- Updated brush size increase/decrease keybindings to clamp between
1-250 (previously 1-100) to match the refactored slider limits.
- Added setting for color picker keybinding
- **Breaking**: None
## Review Focus
- Verify the stacked layout (label + number input above slider) works
well across different panel widths
- Confirm all slider controls properly sync with their corresponding
number inputs
- Test brush size keybindings (increase/decrease) respect the new 1-250
limits
## Screenshot
<img width="1713" height="848" alt="image"
src="https://github.com/user-attachments/assets/22a26ad2-61be-4031-92d0-b4577a003552"
/>
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7783-Fixed-Brush-Settings-Port-Refactor-and-Added-Numeric-Control-2d76d73d365081bda7a8e12d3c649085)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Alexander Brown <drjkl@comfy.org>
### Problem
The "Validate workflow links" test fails because workflow validation is
disabled by default, preventing toast notifications from appearing.
### Solution
Enable the `Comfy.Validation.Workflows` setting before loading the
bad_link workflow in the test.
### Changes
Modified `browser_tests/tests/graph.spec.ts` to enable workflow
validation setting before test execution
### Root Cause
The `Comfy.Validation.Workflows` setting defaults to `false` (per
`src/stores/settingStore.ts`). Without this setting enabled, the
validation code path in `src/scripts/app.ts#L1085` is skipped, so no
toast notifications are generated.
## Testing
- Test now passes locally and should pass in CI
- Verified setting enables validation flow that generates expected 2
toasts:
1. "Workflow Validation" with validation logs
2. "Workflow Links Fixed" confirming successful fixes
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7833-fix-enable-workflow-validation-2dc6d73d36508152b863f2e64ae57ecb)
by [Unito](https://www.unito.io)
Add AMD ROCm GPU option to the desktop installer
## What changed
- Add an AMD GPU choice to the installer picker with updated recommended
badge logic, logo asset, and i18n copy.
- Accept and auto-select the new `amd` device type in the install flow
when it is detected.
- Update `@comfyorg/comfyui-electron-types` and lockfile entries
required for the new device enum.
## Why
- Desktop users with AMD GPUs need a first-class install path instead of
falling back to CPU/manual options.
- This reuses the existing picker/device model to keep the change scoped
and consistent with current UX.
- Tradeoffs: torch mirror selection still falls back to the CPU mirror
for AMD until a dedicated ROCm mirror is available.
## Evidence
- Interactive Storybook file
`apps/desktop-ui/src/components/install/GpuPicker.stories.ts`
<img width="1377" height="834" alt="image"
src="https://github.com/user-attachments/assets/34145f46-d8cc-4e59-b587-0ab5ee79f888"
/>
- Set canvas.read_only directly when spacebar pressed
- Skip stopPropagation when read_only is true in slot link handler
- Remove manual dragging_canvas and processMouseMove management
- Litegraph handles panning through its normal event handlers
- Refactored spacebar forwarding to use useMagicKeys from VueUse instead of raw event listeners
- Added filtering for editable elements (input, textarea, contentEditable)
- Changed panning check in useSlotLinkInteraction to derive button state from event.buttons instead of storing canvas.pointer.isDown statefully
- Updated tests to work with the new useMagicKeys approach using vi.hoisted pattern
## Summary
Filters out the "nlf" (no-license-file) model type from the Upload Model
wizard's model type dropdown, preventing users from selecting this
internal category.
## Changes
- **What**: Added DISALLOWED_MODEL_TYPES constant and filter in
useModelTypes composable
- **Scope**: Only affects Upload Model flow (used by UploadModelDialog
and UploadModelConfirmation)
## Test plan
- [ ] Open Upload Model dialog and verify "nlf" does not appear in model
type dropdown
- [ ] Verify other model types still appear correctly
- [ ] Verify dropdown still functions as expected
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7793-feat-Filter-out-nlf-model-type-from-Upload-Model-flow-2d86d73d3650811f88e1fcc8dd7040cd)
by [Unito](https://www.unito.io)
Co-authored-by: Claude <noreply@anthropic.com>
Forward keydown events to litegraph's processKey when Vue nodes have
focus. Litegraph only binds keydown to the canvas element, so spacebar
panning didn't work when Vue nodes were focused.
Also sync pointer state with litegraph canvas during link dragging to
enable spacebar panning while dragging connections.
Fixes#7806
Use useI18n for media asset action translations and fix missing
translation string.
## What changed
- Switch the media asset actions composable to use `useI18n()` instead
of the global `t`.
- Use the existing `mediaAsset.selection.downloadsStarted` key for the
single-download toast to avoid missing strings.
## Why
- Aligns translation usage with the composition API and avoids
referencing a non-existent key.
- Reuses existing translation keys without adding new strings.
## Evidence
- Tests: `pnpm lint:fix`, `pnpm typecheck`, `pnpm knip`
## References
- N/A
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7744-Use-useI18n-in-media-asset-actions-2d26d73d365081f79cd1c5af105fc59b)
by [Unito](https://www.unito.io)
# Background
Currently, validation warnings about zod schema violations are shown to
all users when loading workflows. These warnings appear in a dialog that
users must dismiss, and they reappear every time the workflow is
reloaded.
## User Pain Points
- Many users (especially from the Chinese community) are asking how to
disable these alerts
- The zod schema information is too technical for end users
- Users don't understand what action they should take when seeing the
warning
- The warnings cannot be permanently dismissed - they reappear every
time
- The warnings don't actually prevent workflow execution
## Problem Statement
The validation warning just means the serialized workflow doesn't
conform to the official schema. Sometimes that makes the workflow
unusable; sometimes it still runs fine. While these checks have
historically surfaced real issues and are important for maintaining
static types internally, the current UX isn't helpful to regular users.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7795-disable-workflow-validation-warnings-by-default-2d86d73d36508102a0f7c46d43189e38)
by [Unito](https://www.unito.io)
## Summary
Use a pre-built container image with all dependencies for Playwright E2E
tests, eliminating ~130s setup time per shard.
## Changes
- Use `ghcr.io/comfy-org/comfyui-ci-container:0.0.8` container for test
jobs
- Container includes: Playwright browsers, Node.js, pnpm, Python,
ComfyUI backend (v0.5.1), all Python deps
- Simplified setup: just copy devtools and start server (no cloning, no
pip install, no browser setup)
- Add `version-bump*` to `branches-ignore` to skip E2E tests for version
bump PRs
- Replace cache with artifacts (cache doesn't work inside containers)
## Benefits
- ~130s faster per shard (no ComfyUI clone, no pip install, no browser
download)
- Consistent environment across all test jobs
- Simpler workflow configuration
## Container Image
Repository: https://github.com/comfy-org/comfyui-ci-container
Image: `ghcr.io/comfy-org/comfyui-ci-container:0.0.8`
## Test plan
- [x] Verify CI workflow runs with container
- [x] Verify Playwright tests pass
- [x] Verify snapshot updates work correctly
---------
Co-authored-by: github-actions <github-actions@github.com>
## Summary
Fixes the cancel button on queue job items to properly handle pending
(queued) jobs.
## Problem
The cancel button was calling `api.interrupt()` for all jobs, but
interrupt only affects running/initializing jobs. For pending jobs, it
silently fails with log message: `"Prompt ... is not currently running,
skipping interrupt"`.
The "Cancel job" option in the context menu worked correctly because it
checks the job state first.
Reported in #7758.
## Changes
Update `onCancelItem` in `QueueProgressOverlay.vue` to mirror the
behavior of `cancelJob()` in `useJobMenu.ts`:
- Check `item.state` before deciding which API to call
- Call `api.interrupt(promptId)` for `running` or `initialization`
states
- Call `api.deleteItem('queue', promptId)` for `pending` state
- Refresh queue state after cancel action with `queueStore.update()`
## Testing
- All 3816 unit tests pass
- Type check passes
- Lint passes (prettier, oxlint, eslint)
## Steps to Reproduce (before fix)
1. Queue more than 1 job
2. Open job history
3. Click "Cancel" button on any "in queue" job
4. Observe nothing happens (job remains in queue)
After this fix, clicking Cancel on a pending job will remove it from the
queue.
Fixes#7758
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7788-fix-queue-Cancel-button-now-works-for-pending-jobs-2d86d73d365081b3957fdf1d5d677809)
by [Unito](https://www.unito.io)
---------
Co-authored-by: RUiNtheExtinct <deepkarma001@gmail.com>
## Problem
When sidebar is positioned on the right, the properties panel also
appears on the right, causing both panels to compete for space and
creating a poor layout.
## Solution
Properties panel now dynamically positions itself opposite to the
sidebar:
- Sidebar left → Properties panel right (default)
- Sidebar right → Properties panel left
## Changes
- Modified `LiteGraphCanvasSplitterOverlay.vue` to conditionally render
properties panel based on sidebar location
- Updated splitter refresh key to recalculate layout when sidebar
position changes
- Added dynamic close button icon in `RightSidePanel.vue` that points in
the correct direction
## Testing
- Created E2E tests to verify positioning behavior
- Manually verified visual behavior in browser
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7647-feat-position-properties-panel-opposite-to-sidebar-2ce6d73d365081049683e74c8d03dbdd)
by [Unito](https://www.unito.io)
## Summary
Ensure the templates locale Playwright test validates localized UI text
instead of waiting on a flaky network request.
## Changes
- **What**: Update `Templates >> Uses proper locale files for templates`
to assert on French strings rendered in the dialog and confirm English
fallback is absent
## Review Focus
- Confirm the chosen French strings always appear when the localized
bundle loads so the test meaningfully covers the regression
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7705-test-deflake-templates-locale-coverage-2d16d73d365081ffbf9adc1623a36733)
by [Unito](https://www.unito.io)
# Fix Import Failed Warning Icon
## Problem Description
Warning icons were not displayed when import failed errors occurred in
installed packages.
## Root Cause
Conflict detection logic mismatch between `PackCardFooter` and
`PackEnableToggle`:
- **PackCardFooter**: Uses `checkNodeCompatibility()`
- System compatibility check **before** installation (OS, accelerator,
version, etc.)
- Does not include import failed information
- **PackEnableToggle**: Uses `getConflictsForPackageByID()`
- Actual conflict data **after** installation (including import failed)
- But was dependent on parent component's `hasConflict` prop
## Changes Made
### 1. PackEnableToggle.vue
```diff
- <div v-if="hasConflict">
+ <div v-if="packageConflict?.has_conflict">
```
- Removed `hasConflict` prop dependency
- Changed to use only internal store data (`packageConflict`)
### 2. PackCardFooter.vue
```diff
- <PackEnableToggle :has-conflict="hasConflicts" :node-pack="nodePack" />
+ <PackEnableToggle :node-pack="nodePack" />
```
- Removed unnecessary `has-conflict` prop passing
## Result
- ✅ Warning icon properly displays for installed packages with import
failed errors
- ✅ Conflict modal works correctly when clicked
- ✅ Each component uses appropriate conflict detection logic
[after.webm](https://github.com/user-attachments/assets/80576018-0a5b-4e32-9df6-686be3774313)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7753-fix-import-fail-info-warning-icon-2d36d73d365081518fbeedf539a19040)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: github-actions <github-actions@github.com>
#7435 introduced a tricky regression which will cause extremely small
levels of zoom with nodes spread far apart when in vue mode. I am able
to consistently reproduce this behaviour by
- Being in vue mode
- Swapping to a different tab so that ComfyUI is in the background
- Making a pointless line change to frontend code so that vite forces a
reload
- Waiting ~1 minute to ensure the reload completes
- Swapping back to the ComfyUI tab
From testing, if a reload occurs while the tab is backgrounded, the
canvas has an uninitialized size of 300x150. This PR proposes falling
back to a more sane default width and height of 1920x1080 if it is
detected that the canvas element is unitialized.
| Before | After |
| ------ | ----- |
| <img width="360" alt="before"
src="https://github.com/user-attachments/assets/8e19fc98-7187-4008-98cc-fb5ea3bcdce2"/>
| <img width="360" alt="after"
src="https://github.com/user-attachments/assets/add88614-3451-44df-ae9a-b0b867486459"
/>|
This appears to have consistently good results, but second opinions or
further testing would be appreciated. A more reasonable option (like
skipping this automatic fitView if the canvas has uninitialized size) is
likely to be safer, even if it results in a return of edge cases
resulting in a graph having no nodes in view after load.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7751-Workaround-for-reload-causing-node-spread-2d36d73d365081b9ae74d5f0e6f436f5)
by [Unito](https://www.unito.io)
