Fixes a bug where swapping to a different workflow from the inside of a
subgraph would cause nodes to be in an incorrect position after swapping
back. in vue mode
Prior to an unknown-but-recent PR, all nodes would would stack on the
origin. This PR instead solves the remaining issue where having
`ComfyEnableWorkflowViewRestore` would cause incorrect node positions.
This is done by not delaying the fitView by a frame (which causes it to
occur after the graph is no longer in the configuring state). In order
to accomplish this, the code in LGraphNode has been updated to allow
measuring node bounds without requiring a ctx argument. This arg is only
used to ensure sufficient width for a node's title and is irrelevant
when loading an existing graph.
| Before | After |
| ------ | ----- |
| <img width="360" alt="before"
src="https://github.com/user-attachments/assets/7f73817b-36e9-4400-8342-9e660cb36628"/>
| <img width="360" alt="after"
src="https://github.com/user-attachments/assets/c7ab4b99-2797-4276-9703-58d489cc3eaf"
/>|
See also #7591, which solves similar issues, but does not resolve this
bug.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7645-Do-not-delay-fit-to-view-on-graph-restore-2ce6d73d36508153972cc7b5948ce375)
by [Unito](https://www.unito.io)
With reactivity fixed, control widgets would apply twice. This is fixed
by using the litegraph implementation.
Also adds control widget support for combos
Followup to #7539.
Known Issue:
- Primitive node do not have litegraph callbacks properly setup. As a
result, they will display an updated value when modified by control
widgets. Fixing this will requires a larger, separate PR
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7550-Fix-doubled-control-application-2cb6d73d365081739a2fc40fdfb3630e)
by [Unito](https://www.unito.io)
## Summary
This change extends
https://github.com/Comfy-Org/ComfyUI_frontend/pull/7154 by making sure
the `prompt` metadata tag is parsed before the legacy A1111 fallback
when files are dropped onto the canvas.
ComfyUI embeds two structured payloads into every first-class export
format we support (PNG, WEBP, WEBM, MP4/MOV/M4V, GLB, SVG, MP3,
OGG/FLAC, etc.): `workflow`, which is the full editor JSON with layout
state, and `prompt`, which is the API graph sent to `/prompt`.
During import we try format-specific decoders first and only as a last
resort look for an A1111 file by scanning text chunks for a `parameters`
entry. That compatibility path was always meant to be a best-effort
option, but when we refactored the loader it accidentally enforced the
order `workflow → parameters → prompt`. As soon as a dropped asset
contained a `parameters` chunk—something Image Saver’s “A1111
compatibility” mode always adds—the A1111 converter activated and
blocked the subsequent `prompt` loading logic.
PR #7154 already lifted `workflow` ahead of the fallback, yet any file
lacking the `workflow` chunk but holding both `prompt` and `parameters`
still regressed. Reordering to `workflow → prompt → parameters`
preserves the compatibility shim for genuine A1111 exports while
guaranteeing native Comfy metadata always wins, eliminating the entire
class of failures triggered merely by the presence of the word
`parameters` in an unrelated metadata chunk.
Fixes https://github.com/Comfy-Org/ComfyUI_frontend/issues/7096, fixes
https://github.com/Comfy-Org/ComfyUI_frontend/issues/6988
## Related
(fixed by https://github.com/Comfy-Org/ComfyUI_frontend/pull/7154)
- https://github.com/Comfy-Org/ComfyUI_frontend/issues/6633
- https://github.com/Comfy-Org/ComfyUI_frontend/issues/6561
---------
Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Prior to the release of subgraphs, there was a single graph accessed
through `app.graph`. Now that there's multiple graphs, there's a lot of
code that needs to be reviewed and potentially updated depending on if
it cares about nearby nodes, all nodes, or something else requiring
specific attention.
This was done by simply changing the type of `app.graph` to unknown so
the typechecker will complain about every place it's currently used.
References were then updated to `app.rootGraph` if the previous usage
was correct, or actually rewritten.
By not getting rid of `app.graph`, this change already ensures that
there's no loss of functionality for custom nodes, but the prior typing
of `app.graph` can always be restored if future dissuasion of
`app.graph` usage creates issues.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7399-Cleanup-app-graph-usage-2c76d73d365081178743dfdcf07f44d0)
by [Unito](https://www.unito.io)
## Summary
Add frontend setting to override live preview method per prompt
execution.
## Changes
- **What**: New setting `Comfy.Execution.PreviewMethod` allows users to
override preview method (default/none/auto/latent2rgb/taesd) from
frontend. Applied to Queue Prompt, Queue Front, Run Selected Nodes, and
Auto Queue.
- **Dependencies**: Requires backend support from
comfyanonymous/ComfyUI#11261
## Review Focus
- `'default'` option does not send `preview_method` to backend (uses
server CLI setting)
- Legacy UI intentionally not modified (deprecated, maintains backward
compatibility)
- `versionAdded: '1.35.3'` assigned tentatively; adjust as needed for
actual release version
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7385-feat-add-live-preview-method-setting-for-prompt-execution-2c66d73d365081759c9cebaec29f451c)
by [Unito](https://www.unito.io)
## Summary
- Allow default browser copy (Ctrl+C / Cmd+C) when text is selected
anywhere in the document
- Previously, the graph node copy handler intercepted copy events even
in dialogs
## Problem
Users could not copy error messages from the PromptExecutionError dialog
or other modal dialogs. When pressing Ctrl+C with text selected in a
dialog, the graph copy handler would intercept the event and prevent the
default browser copy behavior.
## Solution
Add a `hasTextSelection()` check to `shouldIgnoreCopyPaste()`. When the
user has any text selected in the document, the function returns `true`,
allowing the default browser copy to proceed.
## Test plan
- [ ] Open an error dialog (trigger a workflow error)
- [ ] Click "Show Report" to expand error details
- [ ] Select some text in the dialog
- [ ] Press Ctrl+C (or Cmd+C on Mac)
- [ ] Paste elsewhere to verify the text was copied
- [ ] Verify graph node copy still works when no text is selected
https://github.com/user-attachments/assets/30a0c501-95ee-4148-b321-3d60339a41c5
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7166-Fix-copy-not-working-when-text-is-selected-in-dialogs-2bf6d73d36508182a240fd3153cb6969)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
…s metadata
- Reorder handleFile() to check workflow before parameters
- Add validation to prevent JSON parse errors from crashing imports
- Fix loadGraphData() to use explicit type validation instead of falsy
check
- Ensures ComfyUI-generated PNGs with both metadata types load the
workflow, not parameters
Fixes issue where large workflows (e.g., 634 nodes) were replaced with
basic A1111 format when importing PNG files.
## Summary
Fixed workflow loading from PNG images to prioritize workflow metadata
over parameters, preventing large workflows from being replaced with
basic A1111 format.
## Changes
- **What**: Reordered `handleFile()` to check workflow before
parameters, added JSON parse error handling and validation, fixed
`loadGraphData()` to use explicit type checking instead of falsy check
- **Dependencies**: None
## Review Focus
The key issue was in `handleFile()` where parameters were checked before
workflow, causing ComfyUI-generated PNGs (which contain both workflow
and parameters metadata) to incorrectly import as A1111 format. The fix
ensures:
1. Workflow is always checked first and validated properly
2. Parameters are only used as a fallback when no workflow exists
3. Invalid/malformed workflow data doesn't crash the import process
Additionally, `loadGraphData()` was using a falsy check (`if
(!graphData)`) which could incorrectly replace valid but falsy values.
Now uses explicit type validation.
Tested with real-world PNG containing 634-node workflow (780KB) +
parameters (1KB) - now correctly loads the workflow instead of
discarding it.
<!-- Fixes #ISSUE_NUMBER -->
## Screenshots (if applicable)
N/A - Backend logic fix, no UI changes
Fixes#6633
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7154-Fix-workflow-loading-from-PNG-images-with-both-workflow-and-parameter-2bf6d73d365081ecb7a6c4bf6b6ccd51)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Alexander Brown <DrJKL0424@gmail.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Adds a workflow progress panel component underneath the
`actionbar-container`.
I suggest starting a review at the extraneous changes that were needed.
Including but not limited to:
- `get createTime()` in queueStore
- `promptIdToWorkflowId`, `initializingPromptIds`, and
`nodeProgressStatesByPrompt` in executionStore
- `create_time` handling in v2ToV1Adapter
- `pointer-events-auto` on ComfyActionbar.vue
The rest of the changes should be contained under
`QueueProgressOverlay.vue`, and has less of a blast radius in case
something goes wrong.
---------
Co-authored-by: pythongosssss <125205205+pythongosssss@users.noreply.github.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: Jin Yi <jin12cc@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: Johnpaul Chiwetelu <49923152+Myestery@users.noreply.github.com>
Co-authored-by: Christian Byrne <cbyrne@comfy.org>
Co-authored-by: Comfy Org PR Bot <snomiao+comfy-pr@gmail.com>
Co-authored-by: christian-byrne <72887196+christian-byrne@users.noreply.github.com>
## Summary
- Merged separate Cloud and OSS workflow warning modals into single
unified modal
- Removed legacy LoadWorkflowWarning.vue
- Renamed CloudMissingNodes* components to MissingNodes* for clarity
- Environment branching now handled internally via isCloud flag
- Restructured i18n: removed loadWorkflowWarning, added
missingNodes.cloud/oss sections
- Improved OSS button styling to match Cloud consistency
## Key Changes
- **OSS**: "Open Manager" + "Install All" buttons
- **Cloud**: "Learn More" + "Got It" buttons (unchanged)
- Single unified modal displays different UI/text based on environment
## 📝 Note on File Renames
This PR renames the following files:
- `CloudMissingNodesHeader.vue` → `MissingNodesHeader.vue` (R053, 53%
similarity)
- `CloudMissingNodesContent.vue` → `MissingNodesContent.vue` (R067, 67%
similarity)
- `LoadWorkflowWarning.vue` → `MissingNodesFooter.vue` (R051, 51%
similarity)
- `CloudMissingNodesFooter.vue` → Deleted (replaced by new
MissingNodesFooter)
**Why GitHub PR UI doesn't show renames properly:**
GitHub detects renames only when file similarity is above 70%. In this
PR, the Cloud/OSS unification significantly modified file contents,
resulting in 51-67% similarity.
However, **Git history correctly records these as renames**. You can
verify with:
```bash
git show <commit-hash> --name-status
```
While GitHub UI shows "additions/deletions", these are actually rename +
modification operations.
## Test Plan
- [x] Test OSS mode: missing nodes modal shows "Open Manager" and
"Install All" buttons
- [x] Test Cloud mode: missing nodes modal shows "Learn More" and "Got
It" buttons
- [x] Verify Install All button functionality in OSS
- [x] Verify modal closes automatically after all nodes are installed
(OSS)
[missingnodes.webm](https://github.com/user-attachments/assets/36d3b4b0-ff8b-4b45-824c-3bc15d93f1a2)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6673-refactor-Unify-Cloud-OSS-Missing-Nodes-modal-2aa6d73d365081a88827d0fa85db4c63)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
- Implement pagination for media assets history to handle large datasets
efficiently
- Add infinite scroll support with approach-end event handler
- Support offset parameter in history API for both V1 and V2 endpoints
## Changes
- Add offset parameter support to `api.getHistory()` method
- Update history fetchers (V1/V2) to include offset in API requests
- Implement `loadMoreHistory()` in assetsStore with pagination state
management
- Add `loadMore`, `hasMore`, and `isLoadingMore` to IAssetsProvider
interface
- Add approach-end handler in AssetsSidebarTab for infinite scroll
- Set BATCH_SIZE to 200 for efficient loading
## Implementation Improvements
Simplified offset-based pagination by removing unnecessary
reconciliation logic:
- Remove `reconcileHistory`, `taskItemsMap`, `lastKnownQueueIndex`
(offset is sufficient)
- Replace `assetItemsByPromptId` Map → `loadedIds` Set (store IDs only)
- Replace `findInsertionIndex` binary search → push + sort (faster for
batch operations)
- Replace `loadingPromise` → `isLoadingMore` boolean (simpler state
management)
- Fix memory leak by cleaning up Set together with array slice
## Test Plan
- [x] TypeScript compilation passes
- [x] ESLint and Prettier formatting applied
- [x] Test infinite scroll in media assets tab
- [x] Verify network requests include correct offset parameter
- [x] Confirm no duplicate items when loading more
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.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
Implements a cloud-specific dialog to warn users when loading workflows
with unsupported custom nodes in Comfy Cloud. The new dialog follows the
visual style of the node conflict dialog and provides appropriate
messaging and actions.
## Changes
- Add `CloudMissingNodesHeader`, `CloudMissingNodesContent`, and
`CloudMissingNodesFooter` components
- Add `showCloudLoadWorkflowWarning` to dialogService
- Update app.ts to show cloud dialog when in cloud environment
- Add `cloud.missingNodes` translations
## Screenshots
The dialog displays:
- Warning icon and title
- Description of the issue
- List of missing nodes
- "Learn more" link and "Ok, got it" button
## Test plan
1. Load a workflow with custom nodes in cloud environment
2. Verify cloud-specific dialog appears with appropriate styling
3. Verify "Learn more" button opens cloud documentation
4. Verify "Ok, got it" button closes dialog
## Notes
- Two unused i18n keys (`cloud.missingNodes.cannotRun` and
`cloud.missingNodes.missingNodes`) are included for future PR that will
add breadcrumb warning icons and run button disable functionality
<img width="1367" height="988" alt="스크린샷 2025-11-12 오후 4 33 38"
src="https://github.com/user-attachments/assets/75a6fced-959f-4e93-9b82-4e61b53a9ee4"
/>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6659-Add-cloud-specific-missing-nodes-warning-dialog-2a96d73d36508161ae55fe157f55cd17)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR cleans up the base-layer utilities so they no longer pull
renderer or workbench code. The renderer-only `isPrimitiveNode` guard
now lives in `src/renderer/utils/nodeTypeGuards.ts`, and the node
help/model/ordering helpers have moved into `src/workbench/utils`. All
affected services, stores, scripts, and tests were updated to import
from the new locations.
The idea is to reduce the number of Base→Renderer/Base→Workbench edges
(higher scoped base/common utils should not import from
renderer/workbench layers).
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6621-refactor-move-renderer-dependent-utils-into-workbench-scope-2a36d73d36508167aff0fc8a22202d7f)
by [Unito](https://www.unito.io)
## Summary
- Resolves multiple cloud environment issues when accessing
`/cloud/user-check` directly
- Fixes API routing problems that caused 304 Not Modified errors and
JSON parsing failures
- Maintains compatibility with subpath deployments for OSS users
## Root Cause
The `api_base` was incorrectly calculated as `/cloud` on cloud SPA
routes, causing API calls to use wrong paths like `/cloud/api/user`
instead of `/api/user`.
## Issues Fixed
- ❌ `/cloud/user-check` direct access resulted in infinite loading
- ❌ JSON parsing errors: `Unexpected token '<', "<!DOCTYPE "... is not
valid JSON`
- ❌ 304 Not Modified responses on `/cloud/api/user`,
`/cloud/api/settings/onboarding_survey`, `/cloud/api/system_stats`
## Solution
Added conditional `api_base` calculation in `ComfyApi` constructor:
- **Cloud SPA routes** (`/cloud/*`): Use empty `api_base` → API calls
use `/api/*` paths
- **Regular deployments**: Keep existing logic → Supports subpath
deployments
## Test Plan
- [x] Verify `/cloud/user-check` direct access works without infinite
loading
- [x] Verify all API calls return 200 instead of 304
- [x] Verify OSS subpath deployment compatibility unchanged
- [x] Test authentication flow completion
🤖 Generated with [Claude Code](https://claude.ai/code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6572-Fix-cloud-routing-issues-caused-by-incorrect-api_base-calculation-2a16d73d36508163aeb2cbf6347b427d)
by [Unito](https://www.unito.io)
## Summary
Deduplicates workflow run telemetry and keeps a single source of truth
for execution while retaining click analytics and attributing initiator
source.
- Keep execution tracking in one place via `trackWorkflowExecution()`
- Keep click analytics via `trackRunButton(...)`
- Attribute initiator with `trigger_source` = 'button' | 'keybinding' |
'legacy_ui'
- Remove pre‑tracking from keybindings to avoid double/triple counting
- Update legacy UI buttons to emit both click + execution events (they
bypass commands)
## Problem
PR #6499 added tracking at multiple layers:
1) Keybindings tracked via a dedicated method and then executed a
command
2) Menu items tracked via a dedicated method and then executed a command
3) Commands also tracked execution
Because these ultimately trigger the same command path, this produced
duplicate (sometimes triplicate) events per user action and made it hard
to attribute initiator precisely.
## Solution
- Remove redundant tracking from keybindings (and previous legacy menu
handler)
- Commands now emit both:
- `trackRunButton(...)` (click analytics, includes `trigger_source` when
provided)
- `trackWorkflowExecution()` (single execution start; includes the last
`trigger_source`)
- Legacy UI buttons (which call `app.queuePrompt(...)` directly) now
also emit both events with `trigger_source = 'legacy_ui'`
- Add `ExecutionTriggerSource` type and wire `trigger_source` through
provider so `EXECUTION_START` matches the most recent click intent
### Telemetry behavior after this change
- `RUN_BUTTON_CLICKED` (click analytics)
- Emitted when a run is initiated via:
- Button: `trigger_source = 'button'`
- Keybinding: `trigger_source = 'keybinding'`
- Legacy UI: `trigger_source = 'legacy_ui'`
- `EXECUTION_START` (execution lifecycle)
- Emitted once per run at start; includes `trigger_source` matched to
the click intent above
- Paired with `EXECUTION_SUCCESS` / `EXECUTION_ERROR` from execution
handlers
## Benefits
- ✅ Accurate counts by removing duplicated run events
- ✅ Clear initiator attribution (button vs keybinding vs legacy UI)
- ✅ Separation of “intent” (click) vs. “lifecycle” (execution)
- ✅ Simpler implementation and maintenance
## Files Changed (high level)
- `src/services/keybindingService.ts`: Route run commands with
`trigger_source = 'keybinding'`
- `src/components/actionbar/ComfyRunButton/ComfyQueueButton.vue`: Send
`trigger_source = 'button'` to commands
- `src/scripts/ui.ts`: Legacy queue buttons emit `trackRunButton({
trigger_source: 'legacy_ui' })` and `trackWorkflowExecution()`
- `src/composables/useCoreCommands.ts`: Commands emit
`trackRunButton(...)` + `trackWorkflowExecution()`; accept telemetry
metadata
- `src/platform/telemetry/types.ts`: Add `ExecutionTriggerSource` and
optional `trigger_source` in click + execution payloads
- `src/platform/telemetry/providers/cloud/MixpanelTelemetryProvider.ts`:
Carry `trigger_source` from click → execution and reset after use
- `src/stores/commandStore.ts`: Allow commands to receive args (for
telemetry metadata)
- `src/extensions/core/groupNode.ts`: Adjust command function signatures
to new execute signature
## Related
- Reverts the multi‑event approach from #6499
- Keeps `trackWorkflowExecution()` as the canonical execution event
while preserving click analytics and initiator attribution with
`trackRunButton(...)`
┆Issue is synchronized with this Notion page by Unito
---------
Co-authored-by: Christian Byrne <c.byrne@comfy.org>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: Benjamin Lu <benjaminlu1107@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Problem
401 authentication errors were persistently occurring when calling
log-related APIs in the Cloud environment.
## Root Cause
- Frontend was calling `/internal/logs/*` endpoints in all environments
- Cloud backend provides public APIs at `/api/logs/*` (no authentication
required)
- OSS (open source) backend uses `/internal/logs/*` paths
- This caused Cloud to call non-existent paths → resulting in 401 errors
## Solution
Modified to use appropriate API endpoints based on environment using the
`isCloud` flag:
- Cloud environment: Use `/api/logs/*`
- OSS environment: Use `/internal/logs/*`
## Changes
- `getLogs()`: Added environment-specific URL branching
- `getRawLogs()`: Added environment-specific URL branching
- `subscribeLogs()`: Added environment-specific URL branching
## Testing
- [x] Verified log functionality works correctly in local (OSS)
environment
- [x] Confirmed 401 errors are resolved in Cloud environment
## Related Issues
This resolves the 401 errors tracked in Sentry for log API endpoints.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6539-fix-Use-environment-specific-log-API-endpoints-for-Cloud-and-OSS-29f6d73d365081da9e77f8b55556ca81)
by [Unito](https://www.unito.io)
Summary
- Add new telemetry event: `app:run_triggered` with `{ trigger_source:
'button' | 'keybinding' | 'menu' }`.
- Instrument all run initiation paths:
- UI Queue button emits `run_triggered` (source `button`) and keeps
emitting `run_button_click` for UI-only tracking.
- Keybindings (Ctrl+Enter / Ctrl+Shift+Enter) emit `run_triggered`
(source `keybinding`).
- Menus (menubar + legacy menu buttons) emit `run_triggered` (source
`menu`).
- Mixpanel provider now supports `trackRunTriggered` and forwards
`run_triggered`.
- `execution_start` tracking remains unchanged.
Motivation
GTM observed more `execution_start` events than `run_button_click`. This
change clarifies attribution by adding a unified event across all
triggers while preserving the UI-only `run_button_click` metric.
Files
- src/platform/telemetry/types.ts: Add `RunTriggeredMetadata`,
`RUN_TRIGGERED`, provider method signature.
- src/platform/telemetry/providers/cloud/MixpanelTelemetryProvider.ts:
Implement `trackRunTriggered`.
- src/components/actionbar/ComfyRunButton/ComfyQueueButton.vue: Emit
`run_triggered` on button path.
- src/services/keybindingService.ts: Emit `run_triggered` when queue
commands are invoked via keybindings.
- src/stores/menuItemStore.ts: Emit `run_triggered` for queue commands
invoked via menubar.
- src/scripts/ui.ts: Emit `run_triggered` for legacy menu queue buttons.
Notes
- `run_button_click` continues to represent UI button presses only.
- `run_triggered` now represents all user-initiated runs with clear
source attribution.
QA
- Cloud build: verify `app:run_triggered` appears with the correct
`trigger_source` for button, keybinding, and menu triggers.
- Verify `app:run_button_click` only fires for the button path.
- Confirm `execution_start` still tracks as before.
If preferred, we can extend `run_triggered` with additional fields
(e.g., queue mode, batchCount) in a follow-up.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6499-feat-telemetry-add-unified-run_triggered-event-for-all-run-initiations-29e6d73d3650819fb481d3e0e925c50f)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
- Adds app:workflow_opened and plumbs open_source across drag/drop,
file-open button, workspace, and templates
- Tracks missing_node_count and missing_node_types for both
workflow_opened and workflow_imported
- Reuses WorkflowOpenSource type for consistency; no breaking changes to
loadGraphData callers (5th param remains options object; openSource
optional)
Validation
- pnpm lint:fix
- pnpm typecheck
Notes
- Telemetry only runs in cloud builds; OSS remains clean.
- loadGraphData telemetry is centralized where missing_node_types is
computed.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6476-feat-telemetry-add-workflow_opened-with-open_source-and-missing-node-metrics-29d6d73d365081f385c0da29958309da)
by [Unito](https://www.unito.io)
---------
Co-authored-by: bymyself <cbyrne@comfy.org>
Summary
Fully Refactored the Load3D module to improve architecture and
maintainability by consolidating functionality into a
centralized composable pattern and simplifying component structure. and
support VueNodes system
Changes
- Architecture: Introduced new useLoad3d composable to centralize 3D
loading logic and state
management
- Component Simplification: Removed redundant components
(Load3DAnimation.vue, Load3DAnimationScene.vue,
PreviewManager.ts)
- Support VueNodes
- improve config store
- remove lineart output due Animation doesnot support it, may add it
back later
- remove Preview screen and keep scene in fixed ratio in load3d (not
affect preview3d)
- improve record video feature which will already record video by same
ratio as scene
Need BE change https://github.com/comfyanonymous/ComfyUI/pull/10025https://github.com/user-attachments/assets/9e038729-84a0-45ad-b0f2-11c57d7e0c9a
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5765-refactor-refactor-load3d-2796d73d365081728297cc486e2e9052)
by [Unito](https://www.unito.io)
## Summary
<!-- One sentence describing what changed and why. -->
## Changes
- **What**: <!-- Core functionality added/modified -->
- **Breaking**: <!-- Any breaking changes (if none, remove this line)
-->
- **Dependencies**: <!-- New dependencies (if none, remove this line)
-->
## Review Focus
<!-- Critical design decisions or edge cases that need attention -->
<!-- If this PR fixes an issue, uncomment and update the line below -->
<!-- Fixes #ISSUE_NUMBER -->
## Screenshots (if applicable)
<!-- Add screenshots or video recording to help explain your changes -->
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6400-Cloud-tracking-v2-29c6d73d365081a1ae32e9337f510a9e)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Arjan Singh <arjan@comfy.org>
## 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
Backport outputs from new cloud history endpoint
Does:
1. Show history in the Queue
2. Show outputs from prompt execution
Does not:
1. Handle appending latest images generated to queue history
2. Making sure that workflow data from images is available from load
(requires additional API call to fetch)
Most of this PR is:
1. Test fixtures (truncated workflow to test).
2. The service worker so I could verify my changes locally.
## Changes
- Add `history_v2` to `history` adapter
- Add tests for mapping
- Do branded validation for promptIds (suggestion from @DrJKL)
- Create a dev environment service worker so we can view cloud hosted
images in development.
## Review Focus
1. Is the dev-only service work the right way to do it? It was the
easiest I could think of.
4. Are the validation changes too heavy? I can rip them out if needed.
## Screenshots 🎃https://github.com/user-attachments/assets/1787485a-8d27-4abe-abc8-cf133c1a52aa
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6288-Feat-history-v2-outputs-2976d73d365081a99864c40343449dcd)
by [Unito](https://www.unito.io)
---------
Co-authored-by: bymyself <cbyrne@comfy.org>
## Summary
Centralized all download functionalities across app. Then changed
downloadFile on the cloud distribution to stream assets via blob fetches
while desktop/local retains direct anchor downloads. This fixes issue
where trying to download cross-origin resources opens them in the
window, potentially losing the user's unsaved changes.
## Changes
- **What**: Moved `downloadBlob` into `downloadUtil`, routed all callers
(3D exporter, recording manager, node template export, workflow/palette
export, Litegraph save, ~~`useDownload` consumers~~) through shared
helpers, and changed `downloadFile` to `fetch` first when `isCloud` so
cross-origin URLs download reliably
- `useDownload` is the exception since we simply cannot do model
downloads through blob (forcing user to transfer the entire model data
twice is bad). Fortunately on cloud, the user doesn't need to download
models locally anyway.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6188-refactor-centralize-all-download-utils-across-app-and-apply-special-cloud-specific-behav-2946d73d365081de9f27f0994950511d)
by [Unito](https://www.unito.io)
Fixed the AUDIO_RECORD widget to display correctly in both rendering
modes:
- Removed conflicting AUDIO_RECORD registration from ComfyWidgets that
was blocking the custom widget implementation in uploadAudio.ts
extension
- Changed canvasOnly flags from true to false on both audioUIWidget and
recordWidget to enable Vue nodes rendering
- Added type override (recordWidget.type = 'audiorecord') after widget
creation to enable Vue component lookup while preserving LiteGraph
button rendering
- Removed unused IAudioRecordWidget type definition
The widget now works correctly:
- LiteGraph mode: Displays as a functional button
- Vue nodes mode: Displays full recording UI with waveform visualization
## Summary
<!-- One sentence describing what changed and why. -->
## Changes
- **What**: <!-- Core functionality added/modified -->
- **Breaking**: <!-- Any breaking changes (if none, remove this line)
-->
- **Dependencies**: <!-- New dependencies (if none, remove this line)
-->
## Review Focus
<!-- Critical design decisions or edge cases that need attention -->
<!-- If this PR fixes an issue, uncomment and update the line below -->
<!-- Fixes #ISSUE_NUMBER -->
## Screenshots (if applicable)
<!-- Add screenshots or video recording to help explain your changes -->
https://github.com/user-attachments/assets/cf6513d4-0a4b-4210-88e2-a948855b5206
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6094-fix-Enable-AUDIO_RECORD-widget-in-both-LiteGraph-and-Vue-nodes-modes-28e6d73d365081faa879f53e3e2dddad)
by [Unito](https://www.unito.io)
---------
Co-authored-by: bymyself <cbyrne@comfy.org>
## Summary
Updates `ComfyApp.getRandParam()` to return an empty string on cloud
builds (detected via `isCloud`), letting hosted deployments rely on HTTP
caching for `/view` assets while local hosts retain the legacy cache
busting. The audio widget helpers now defer to the same method instead
of generating their own random suffix, so every frontend consumer shares
this logic.
This keeps the original overwrite protection for localhost workflows but
removes needless cache misses in the cloud stack, where GCS already
serve strong ETags and there is not really a concern about stale
filenames. Once the backend exposes a deterministic file-version field,
we can delete the remaining local-only randomness entirely.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6105-perf-disable-cache-busting-param-on-cloud-28f6d73d36508181b34afad406fabc59)
by [Unito](https://www.unito.io)
Allow for Right Click -> Save Image to work for the "SaveAnimatedWEBP"
node.
Fixing this revealed other existing issues:
- Attempting to resize the node causes runaway scaling
- Right clicking on the image directly causes a browser context menu
without a save option.
Significant rewriting has been performed to resolve both of these
issues.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6095-Support-Right-Click-Save-for-animated-webp-28e6d73d3650818e85a2ec58c38c2aae)
by [Unito](https://www.unito.io)
This pull request introduces a new audio playback widget for node UIs
and integrates it into the node widget system. The main changes include
the implementation of the `WidgetAudioUI` component, its registration in
the widget registry, and updates to pass node data to the new widget.
Additionally, some logging was added for debugging purposes.
**Audio Widget Implementation and Integration:**
* Added a new `WidgetAudioUI.vue` component that provides audio playback
controls (play/pause, progress slider, volume, options) and loads audio
files from the server based on node data.
* Registered the new `WidgetAudioUI` component in the widget registry by
importing it and adding an entry for the `audioUI` type.
[[1]](diffhunk://#diff-c2a60954f7fdf638716fa1f83e437774d5250e9c99f3aa83c84a1c0e9cc5769bR21)
[[2]](diffhunk://#diff-c2a60954f7fdf638716fa1f83e437774d5250e9c99f3aa83c84a1c0e9cc5769bR112-R115)
* Updated `NodeWidgets.vue` to pass `nodeInfo` as the `node-data` prop
to widgets of type `audioUI`, enabling the widget to access
node-specific audio file information.
**Debugging and Logging:**
* Added logging of `nodeData` in `LGraphNode.vue` and
`WidgetAudioUI.vue` to help with debugging and understanding the data
structure.
[[1]](diffhunk://#diff-a7744614cf842e54416047326db79ad81f7c7ab7bfb66ae2b46f5c73ac7d47f2R188-R189)
[[2]](diffhunk://#diff-71cce190d74c6b5359288857ab9917caededb8cdf1a7e6377578b78aa32be2fcR1-R284)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5627-Vuenodes-audio-widgets-2716d73d365081fbbc06c1e6cf4ebf4d)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Arjan Singh <1598641+arjansingh@users.noreply.github.com>
Co-authored-by: filtered <176114999+webfiltered@users.noreply.github.com>
Co-authored-by: Christian Byrne <cbyrne@comfy.org>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: Jin Yi <jin12cc@gmail.com>
Co-authored-by: DrJKL <DrJKL@users.noreply.github.com>
Co-authored-by: Robin Huang <robin.j.huang@gmail.com>
Co-authored-by: github-actions <github-actions@github.com>
This pull request introduces a new extension API for context menu
customization, allowing extensions to contribute items to both canvas
and node right-click menus. It adds two collection methods to the
`ComfyApp` class to aggregate these menu items from all registered
extensions, and updates the extension interface accordingly.
Comprehensive unit tests are included to verify the correct aggregation
behavior and error handling.
**Extension API for Context Menus:**
* Added optional `getCanvasMenuItems` and `getNodeMenuItems` methods to
the `ComfyExtension` interface, enabling extensions to provide context
menu items for canvas and node right-click menus (`src/types/comfy.ts`).
* Updated type imports to support the new API, including
`IContextMenuValue`, `LGraphCanvas`, and `LGraphNode`
(`src/types/comfy.ts`, `src/scripts/app.ts`).
[[1]](diffhunk://#diff-c29886a1b0c982c6fff3545af0ca8ec269876c2cf3948f867d08c14032c04d66L1-R5)
[[2]](diffhunk://#diff-bde0dce9fe2403685d27b0e94a938c3d72824d02d01d1fd6167a0dddc6e585ddR10)
**Core Implementation:**
* Implemented `collectCanvasMenuItems` and `collectNodeMenuItems`
methods in the `ComfyApp` class to gather menu items from all
extensions, with robust error handling and logging for extension
failures (`src/scripts/app.ts`).
**Testing:**
* Added a comprehensive test suite for the new context menu extension
API, covering aggregation logic, error handling, and integration
scenarios (`tests-ui/tests/extensions/contextMenuExtension.test.ts`).
This is PR 1 of the 3 PRs in the Contextmenu standardizations.
-https://github.com/Comfy-Org/ComfyUI_frontend/pull/5992
-https://github.com/Comfy-Org/ComfyUI_frontend/pull/5993
