## 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"
/>
## 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>
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)
## Summary
Adds HuggingFace as a model import source alongside CivitAI, with
improved UX for model type selection and UTF-8 filename support.
## Changes
- **Import Sources**: Implemented extensible import source handler
pattern supporting both CivitAI and HuggingFace
- **UTF-8 Support**: Decode URL-encoded filenames to properly display
international characters (e.g., Chinese)
- **UX**: Sort model types alphabetically for easier selection
- **Feature Flag**: Added `huggingfaceModelImportEnabled` flag for
gradual rollout
- **i18n**: Use proper template parameters for localized error messages
## Technical Details
- Created `ImportSourceHandler` interface for extensibility
- Refactored existing CivitAI logic into handler pattern
- Added URL validation per source
- Filename decoding handles malformed URLs gracefully
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7540-feat-Add-HuggingFace-model-import-support-2cb6d73d3650818f966cca89244e8c36)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
## Summary
Pass target tier to billing portal API for deep linking to Stripe's
subscription update confirmation screen when user has an active
subscription.
## Changes
- **What**: When a user with an active subscription clicks a tier in
PricingTable, pass the target tier (including billing cycle) to
`accessBillingPortal` which sends it as `target_tier` in the request
body. This enables the backend to create a Stripe billing portal deep
link directly to the subscription update confirmation screen.
- **Dependencies**: Requires comfy-api PR for `POST /customers/billing`
`target_tier` support
## Review Focus
- PricingTable now differentiates between new subscriptions (checkout
flow) and existing subscriptions (billing portal with deep link)
- Type derivation uses `Parameters<typeof
authStore.accessBillingPortal>[0]` to avoid duplicating the tier union
(matches codebase pattern)
- Registry types manually updated to include `target_tier` field (will
be regenerated when API is deployed)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7692-feat-pass-target-tier-to-billing-portal-for-subscription-updates-2d06d73d365081b38fe4c81e95dce58c)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Christian Byrne <cbyrne@comfy.org>
Co-authored-by: GitHub Action <action@github.com>
