Some refactors of subscription composable:
- Swapped cloud subscription response shapes to `type` aliases to
emphasize fixed API payloads.
- Formatted renewal/end dates with the user’s locale instead of
hard-coding `en-US`.
- Reused the single `useFirebaseAuthActions()` instance and passed
`fetchSubscriptionStatus` directly into `wrapWithErrorHandlingAsync` to
trim duplicate wrappers.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6365-refactor-subscription-composable-29b6d73d365081b1b002d52abde8d195)
by [Unito](https://www.unito.io)
This pull request introduces a comprehensive update to the design
system's color management, focusing on establishing semantic color
tokens for both light and dark themes. It replaces many hardcoded color
values and legacy CSS classes throughout the codebase with new semantic
CSS variables, ensuring consistent theming and easier future
maintenance. The changes affect core CSS files as well as numerous Vue
components, aligning their styling with the new design system.
**Design System Foundation**
* Added a wide range of new color variables to `style.css`, including
base colors (e.g., `--color-white`, `--color-black`), additional shades
for sand, azure, cobalt, gold, coral, and magenta, and new alpha
(transparency) colors.
[[1]](diffhunk://#diff-71b6b57a56095b04e47c797a5016149b76b27971cab04b93f033f1f846e0f5a0L52-R87)
[[2]](diffhunk://#diff-71b6b57a56095b04e47c797a5016149b76b27971cab04b93f033f1f846e0f5a0R119-R123)
* Introduced semantic color tokens for both light and dark modes
(`--base-background`, `--primary-background`,
`--destructive-background`, etc.), mapping them to the new base colors
for consistent usage across the application.
[[1]](diffhunk://#diff-71b6b57a56095b04e47c797a5016149b76b27971cab04b93f033f1f846e0f5a0R219-R239)
[[2]](diffhunk://#diff-71b6b57a56095b04e47c797a5016149b76b27971cab04b93f033f1f846e0f5a0R301-R321)
* Exposed semantic tokens as CSS variables (e.g.,
`--color-base-foreground`, `--color-secondary-background`) for use
throughout the app.
**Component Refactoring to Semantic Tokens**
* Updated Vue components and their tests to use the new semantic color
classes (e.g., `bg-base-background`, `text-base-foreground`,
`bg-secondary-background`) instead of hardcoded colors or legacy
dark-theme classes. This affects components such as
`WorkflowTemplateSelectorDialog.vue`, `BypassButton.vue`,
`ExecuteButton.vue`, `MenuOptionItem.vue`, `AssetCard.vue`,
`MediaAssetMoreMenu.vue`, `MediaTitle.vue`, `WidgetFileUpload.vue`,
`WidgetRecordAudio.vue`, `AudioPreviewPlayer.vue`, and
`FormDropdownMenuActions.vue`.
[[1]](diffhunk://#diff-2c860bdc48e907b1b85dbef846599d8376dd02cff90f49e490eebe61371fecedL149-R149)
[[2]](diffhunk://#diff-8ec606ef1100f3a56945ed24cbdc1965050932cd744d4172a3868cdfd23894c0L95-R95)
[[3]](diffhunk://#diff-80b781aeba31712968ae157bb70194e4b72bc73430d1cca6a79d718d839daed6L10-R10)
[[4]](diffhunk://#diff-55fd9056d35e50249dc9f2280017dc99294221fdbe56d8399cea60f8bac499b5L7-R7)
[[5]](diffhunk://#diff-c5e6830e63e2441d2dc70d2ecf7c9b56d0a93821f827e9c5377fc10ae6016f18L30-R32)
[[6]](diffhunk://#diff-a1091d53a4b5d493e045aab5960188d2e7c3b80002e7178427268835fadb5809L30-R30)
[[7]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL6-R6)
[[8]](diffhunk://#diff-7ef9ebd48e6f38a644c1a4e7bae1c7bb818bb959b2d20985974824e299ea5c34L3-R3)
[[9]](diffhunk://#diff-489229f88dfdfd5d883a3ef7fad6effa0790a18a831d5a9d84642dfb246962a2L115-R115)
[[10]](diffhunk://#diff-7bee4b453fc869f546e7150a6e39992ab6442987f80c10f8260b8f3715491997L51-R51)
[[11]](diffhunk://#diff-29348fa2e5b8cec1301a99bdec241379aeefc1747cceeb0c39b7df452ca635ffL41-R41)
[[12]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L24-R24)
**Consistency and Maintainability**
* Ensured hover, active, and selected states use semantic background and
foreground colors for both light and dark themes, improving visual
consistency and simplifying future updates.
[[1]](diffhunk://#diff-2c860bdc48e907b1b85dbef846599d8376dd02cff90f49e490eebe61371fecedL183-R183)
[[2]](diffhunk://#diff-a1091d53a4b5d493e045aab5960188d2e7c3b80002e7178427268835fadb5809L115-R114)
[[3]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL18-R18)
[[4]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL29-R29)
[[5]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL43-R43)
[[6]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL55-R55)
[[7]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL69-R69)
[[8]](diffhunk://#diff-ccdb389a5e355d525dcfa26ecd77519297b6232dd34522411c8bfdd4cde05a1cL83-R83)
[[9]](diffhunk://#diff-2c860bdc48e907b1b85dbef846599d8376dd02cff90f49e490eebe61371fecedL328-R328)
[[10]](diffhunk://#diff-489229f88dfdfd5d883a3ef7fad6effa0790a18a831d5a9d84642dfb246962a2L138-R138)
[[11]](diffhunk://#diff-29348fa2e5b8cec1301a99bdec241379aeefc1747cceeb0c39b7df452ca635ffL119-R119)
[[12]](diffhunk://#diff-29348fa2e5b8cec1301a99bdec241379aeefc1747cceeb0c39b7df452ca635ffL137-R137)
[[13]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L53-R53)
[[14]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L153-R153)
**Removal of Legacy Styles**
* Removed legacy dark-theme class usage and hardcoded color values,
replacing them with semantic tokens to unify the styling approach.
[[1]](diffhunk://#diff-c5e6830e63e2441d2dc70d2ecf7c9b56d0a93821f827e9c5377fc10ae6016f18L30-R32)
[[2]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L24-R24)
[[3]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L53-R53)
[[4]](diffhunk://#diff-d464ebe3a44bec4fda7155e5605bf173612aca409250b7ef6b78920a89ae2044L153-R153)
These changes lay the groundwork for a scalable and maintainable design
system, making it easier to implement future theme changes and ensuring
a consistent look and feel across all components.
## Summary
Implements file explorer-style multi-selection functionality for media
assets in the AssetsSidebarTab component.
## Changes
### Multi-Selection Interactions
- **Normal click**: Single selection (clears previous, selects new)
- **Shift + click**: Range selection (from last selected to current)
- **Ctrl/Cmd + click**: Toggle individual selection
### State Management
- Added `assetSelectionStore` to manage selected asset IDs using Set
- Created `useAssetSelection` composable for selection logic and
keyboard state
### UI Enhancements
- Display selection count in footer (output tab only)
- Interactive selection count that shows "Deselect all" on hover
- Added bulk action buttons for download/delete (UI only)
### Translation Keys
Added new keys under `mediaAsset.selection`:
- `selectedCount`: "{count} selected"
- `deselectAll`: "Deselect all"
- `downloadSelected`: "Download"
- `deleteSelected`: "Delete"
## Test Plan
- [x] Open Assets sidebar tab
- [x] Switch to Generated tab
- [x] Test single selection with normal click
- [x] Test range selection with Shift + click
- [x] Test toggle selection with Ctrl/Cmd + click
- [x] Verify selection count updates correctly
- [x] Test hover interaction on selection count
- [x] Click "Deselect all" to clear selection
- [x] Test bulk action buttons (UI only)
## Notes
- Bulk download/delete functionality to be implemented in separate PR
- Selection UI currently only shows in output (Generated) tab
[screen-capture.webm](https://github.com/user-attachments/assets/740315bd-9254-4af3-a0be-10846d810d65)
## Summary
- Updated weekly-docs-check.yaml to use `PR_GH_TOKEN` secret instead of
`GITHUB_TOKEN`
## Problem
The weekly documentation check workflow uses `GITHUB_TOKEN` when
creating pull requests, which can cause permission issues. The default
`GITHUB_TOKEN` has limited permissions and may not trigger other
workflows or perform certain PR operations.
## Solution
Changed the token in the "Create or Update Pull Request" step from
`secrets.GITHUB_TOKEN` to `secrets.PR_GH_TOKEN` to use a more permissive
token that can properly create and manage PRs.
## Changes Made
- `.github/workflows/weekly-docs-check.yaml:135` - Updated token
parameter
## Test Plan
- Workflow should now successfully create PRs with proper permissions
- Other workflows should be triggered correctly when PRs are created
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6364-fix-Use-PR_GH_TOKEN-instead-of-GITHUB_TOKEN-in-weekly-docs-check-workflow-29b6d73d3650812cbaddc1ea10aeb995)
by [Unito](https://www.unito.io)
Co-authored-by: Claude <noreply@anthropic.com>
## 📋 Overview
Implemented a new Media Assets sidebar tab in ComfyUI for managing
user-uploaded input files and generated output files. This feature
supports both local and cloud environments and is currently enabled only
in development mode.
## 🎯 Key Features
### 1. Media Assets Sidebar Tab
- **Imported** / **Generated** files separated by tabs
- Visual display with file preview cards
- Gallery view support (navigable with arrow keys)
### 2. Environment-Specific Implementation
- **`useInternalMediaAssets`**: For local environment
- Fetches file list via `/files` API
- Retrieves generation task execution time via `/history` API
- Processes history data using the same logic as QueueSidebarTab
- **`useCloudMediaAssets`**: For cloud environment
- File retrieval through assetService
- History data processing using TaskItemImpl
- Auto-truncation of long filenames over 20 characters (e.g.,
`very_long_filename_here.png` → `very_long_...here.png`)
### 3. Execution Time Display
- Shows task execution time on generated image cards (e.g., "2.3s")
- Calculated from History API's `execution_start` and
`execution_success` messages
- Displayed at MediaAssetCard's duration chip location
### 4. Gallery Feature
- Full-screen gallery mode on image click
- Navigate between images with keyboard arrows
- Exit gallery with ESC key
- Reuses ResultGallery component from QueueSidebarTab
### 5. Development Mode Only
- Excluded from production builds using `import.meta.env.DEV` condition
- Feature in development, scheduled for official release after
stabilization
## 🛠️ Technical Changes
### New Files Added
- `src/components/sidebar/tabs/AssetsSidebarTab.vue` - Main sidebar tab
component
- `src/composables/sidebarTabs/useAssetsSidebarTab.ts` - Sidebar tab
definition
- `src/composables/useInternalMediaAssets.ts` - Local environment
implementation
- `src/composables/useCloudMediaAssets.ts` - Cloud environment
implementation
- `packages/design-system/src/icons/image-ai-edit.svg` - Icon addition
### Modified Files
- `src/stores/workspace/sidebarTabStore.ts` - Added dev mode only tab
display logic
- `src/platform/assets/components/MediaAssetCard.vue` - Added execution
time display, zoom event
- `src/platform/assets/components/MediaImageTop.vue` - Added image
dimension detection
- `packages/shared-frontend-utils/src/formatUtil.ts` - Added media type
determination utility functions
- `src/locales/en/main.json` - Added translation keys
[media_asset_OSS_cloud.webm](https://github.com/user-attachments/assets/a6ee3b49-19ed-4735-baad-c2ac2da868ef)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: github-actions <github-actions@github.com>
## Summary
Fixed dropdown components exceeding viewport on mobile/tablet
environments and improved workflow template selector dialog filter
layout.
https://github.com/Comfy-Org/ComfyUI_frontend/issues/6153
## Changes
### 1. Dropdown Height Constraints (MultiSelect & SingleSelect)
- Applied CSS `min()` function to use the smaller value between
`listMaxHeight` prop and 50% viewport height
- Ensures dropdowns don't overflow on devices with smaller viewport
heights like tablets and mobiles
### 2. Workflow Template Dialog Layout Improvements
- Grouped filters (Model, Use Case, License) on the left side
- Positioned Sort by option on the right for clearer visual hierarchy
- Used `justify-between` to place filters and sort options at opposite
ends
## Test Plan
- [ ] Verify dropdown works correctly on desktop browsers
- [ ] Confirm dropdown doesn't exceed 50vh on tablet viewport
- [ ] Confirm dropdown doesn't exceed 50vh on mobile viewport
- [ ] Check workflow template dialog filter/sort layout
## Screenshots
**Before**
[before.webm](https://github.com/user-attachments/assets/64b4b969-54ed-4463-abdf-0a4adef01e72)
**After**
[after.webm](https://github.com/user-attachments/assets/b38973e5-9e77-4882-adf8-306279d302e1)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## 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
Adds a new automated workflow that runs weekly to check and update
documentation accuracy.
## Changes
- Created `.github/workflows/weekly-docs-check.yaml`
- Workflow runs every Monday at 9 AM UTC or via manual dispatch
- Uses Claude to fact-check all documentation against the current
codebase
- Automatically creates/updates a draft PR with documentation
corrections
## Workflow Features
1. **Schedule**: Runs weekly (Mondays at 9 AM UTC) or on-demand via
workflow_dispatch
2. **Documentation Review**: Claude analyzes:
- All markdown files in `docs/`
- Project guidelines in `CLAUDE.md`
- README files throughout the repository
- Claude command documentation in `.claude/commands/`
3. **Automated PR Creation**: Uses `peter-evans/create-pull-request`
action to:
- Create or update the `docs/weekly-update` branch
- Generate a draft PR with all documentation updates
- Apply `documentation` and `automated` labels
## Benefits
- Keeps documentation synchronized with code changes
- Identifies outdated API references and deprecated functions
- Catches missing documentation for new features
- Ensures code examples remain valid and tested
## Test Plan
- [x] YAML syntax validated
- [ ] Workflow can be manually triggered to verify functionality
- [ ] PR creation works as expected
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6298-feat-add-weekly-documentation-accuracy-check-workflow-2986d73d365081d48ce0f4cf181c377f)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
This plugin does not seem to work well with tw v4. Can revert this PR
later.
---
the graph is forcing tailwind-api-utils@1.0.3 which tries to import v3
files, or something like that.
```
> @comfyorg/comfyui-frontend@1.31.0 lint:fix /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31
> eslint src --cache --fix
Oops! Something went wrong! :(
ESLint: 9.35.0
Error: Error while loading rule 'tailwindcss/enforces-negative-arbitrary-values': Cannot find module '/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwindcss@4.1.12/node_modules/tailwindcss/dist/lib/setupContextUtils.js'
Require stack:
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwind-api-utils@1.0.3_tailwindcss@4.1.12/node_modules/tailwind-api-utils/dist/index.cjs
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/customConfig.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/tailwindAPI.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/rules/classnames-order.js
- /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/index.js
Occurred while linting /home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/src/base/common/downloadUtil.ts
at Module._resolveFilename (node:internal/modules/cjs/loader:1410:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1051:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1056:22)
at Module._load (node:internal/modules/cjs/loader:1219:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:238:24)
at Module.require (node:internal/modules/cjs/loader:1493:12)
at require (node:internal/modules/helpers:152:16)
at TailwindUtils.loadConfigV3 (/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/tailwind-api-utils@1.0.3_tailwindcss@4.1.12/node_modules/tailwind-api-utils/dist/index.cjs:429:31)
at getTailwindConfig (/home/c_byrne/projects/comfyui-frontend-testing/ComfyUI_frontend-clone-31/node_modules/.pnpm/eslint-plugin-tailwindcss@4.0.0-beta.0_tailwindcss@4.1.12/node_modules/eslint-plugin-tailwindcss/lib/util/tailwindAPI.js:14:11)
ELIFECYCLE Command failed with exit code 2.
```
This pull request refactors how context menu items are contributed by
extensions in the LiteGraph-based canvas. The legacy monkey-patching
approach for adding context menu options is replaced by a new, explicit
API (`getCanvasMenuItems` and `getNodeMenuItems`) for extensions. A
compatibility layer is added to support legacy extensions and warn
developers about deprecated usage. The changes improve maintainability,
extension interoperability, and migration to the new context menu
system.
### Context Menu System Refactor
* Introduced a new API for extensions to contribute context menu items
via `getCanvasMenuItems` and `getNodeMenuItems` methods, replacing
legacy monkey-patching of `LGraphCanvas.prototype.getCanvasMenuOptions`.
Major extension files (`groupNode.ts`, `groupOptions.ts`,
`nodeTemplates.ts`) now use this new API.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917L1779-R1771)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL232-R239)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL447-R458)
* Added a compatibility layer (`legacyMenuCompat` in
`contextMenuCompat.ts`) to detect and warn when legacy monkey-patching
is used, and to extract legacy-added menu items for backward
compatibility.
[[1]](diffhunk://#diff-2b724cb107c04e290369fb927e2ae9fad03be9e617a7d4de2487deab89d0d018R2-R45)
[[2]](diffhunk://#diff-d3a8284ec16ae3f9512e33abe44ae653ed1aa45c9926485ef6270cc8d2b94ae6R1-R115)
### Extension Migration
* Refactored core extensions (`groupNode`, `groupOptions`, and
`nodeTemplates`) to implement the new context menu API, moving menu item
logic out of monkey-patched methods and into explicit extension methods.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917L1633-L1683)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL19-R77)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL366-R373)
### Type and Import Cleanup
* Updated imports for context menu types (`IContextMenuValue`) across
affected files for consistency with the new API.
[[1]](diffhunk://#diff-b29f141b89433027e7bb7cde57fad84f9e97ffbe5c58040d3e0fdb7905022917R4-L7)
[[2]](diffhunk://#diff-91169f3a27ff8974d5c8fc3346bd99c07bdfb5399984484630125fdd647ff02fL1-R11)
[[3]](diffhunk://#diff-04c18583d2dbfc013888e4c02fd432c250acbcecdef82bf7f6d9fd888e632a6eL2-R6)
[[4]](diffhunk://#diff-bde0dce9fe2403685d27b0e94a938c3d72824d02d01d1fd6167a0dddc6e585ddR10)
### Backward Compatibility and Migration Guidance
* The compatibility layer logs a deprecation warning to the console when
legacy monkey-patching is detected, helping developers migrate to the
new API.
---
These changes collectively modernize the context menu extension
mechanism, improve code clarity, and provide a migration path for legacy
extensions.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5993-Contextmenu-extension-migration-2876d73d3650813fae07c1141679637a)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
## 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)
## Summary
Make some settings dynamic based on whether in cloud or localhost
1. Comfy.Memory.AllowManualUnload (line 18-24)
- Type: 'hidden' on cloud, 'boolean' on localhost
- Default: false on cloud, true on localhost
2. Comfy.Validation.Workflows (line 25-30)
- Default: false on cloud, true on localhost
3. Comfy.Workflow.ShowMissingModelsWarning (line 282-288)
- Type: 'hidden' on cloud, 'boolean' on localhost
- Default: false on cloud, true on localhost
4. Comfy.ModelLibrary.AutoLoadAll (line 387-394)
- Type: 'hidden' on cloud, 'boolean' on localhost
5. Comfy.QueueButton.BatchCountLimit (line 595-603)
- Default: 4 on cloud, 100 on localhost
6. Comfy.Toast.DisableReconnectingToast (line 943-949)
- Default: true on cloud, false on localhost
7. Comfy.Assets.UseAssetAPI (line 1068-1075)
- Default: true on cloud, false on localhost
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6302-change-some-settings-for-cloud-specific-behavior-2986d73d365081169be4ebd11823a7fa)
by [Unito](https://www.unito.io)
## Summary
Create display priority based on execution success timestamps.
Next up is displaying in progress prompts in the queue.
## Review Focus
@DrJKL and I discussed logic and decided for history, execution success
(when the prompt finishes) is the best way to assign priority.
This does differ from existing cloud logic which uses execution start
time.
For prompt progress I intend to create a priority for them based on
start time.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6336-feat-historyV2-create-sythetic-queue-priority-2996d73d365081ffa3a0f8071c178066)
by [Unito](https://www.unito.io)
## Summary
Changed history reconciliation to use `promptId` instead of `queueIndex`
to support cloud environments that don't have queue indices.
Refactored into pure functions with expressive naming.
## Changes
- Use `promptId` (unique UUID) for reconciliation instead of
`queueIndex` (not available in cloud)
- Extract `reconcileHistoryWithServer` with helpers: `extractPromptIds`,
`isAddedAfter`, `sortNewestFirst`
- Added 34 tests covering reconciliation edge cases, sorting, and limits
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6327-use-prompt-id-rather-than-queue-index-for-history-reconciliation-2996d73d3650818e9471dbeb53cc23bb)
by [Unito](https://www.unito.io)
Follow up on https://github.com/Comfy-Org/ComfyUI_frontend/pull/6317:
Fixes confusing "merge conflicts detected" message when commit already
exists on target branch (e.g., PRs #6294 and #6307).
## Changes
- Added check to detect if merge commit already exists on target branch
before attempting cherry-pick
- New failure reason `already-exists` for this case
- Clear comment message: "Commit already exists on branch, no backport
needed" instead of confusing "Merge conflicts detected" with empty file
list
## Before
When a commit already existed on the target branch, users would see:
> @user Backport to `core/1.30` failed: Merge conflicts detected.
> Please manually cherry-pick commit `abc123` to the `core/1.30` branch.
> <details><summary>Conflicting files</summary>
>
> </details>
This was confusing because there were no actual conflicts - the commit
was already present.
## After
Users now see:
> @user Commit `abc123` already exists on branch `core/1.30`. No
backport needed.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6326-ci-leave-comment-and-abort-early-if-commit-already-exists-on-target-branch-in-backport-w-2996d73d36508167aff3e6783e832c74)
by [Unito](https://www.unito.io)
Changes the RC minor version branch release automation to create paired
`core/x.y` and `cloud/x.y` branches whenever a release bump merges.
Then changes the backport workflow to accept labels that match those
branch names directly, allowing engineers to route fixes to either OSS
or cloud release lines without extra labels or artifacts.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6321-ci-automate-cloud-release-branch-tagging-2996d73d365081b0b036ebd3f088354b)
by [Unito](https://www.unito.io)
## Summary
This PR fixes all @intlify/vue-i18n/no-raw-text linting errors
identified in #5625 by replacing raw text strings with proper i18n
translation function calls.
## Changes
Fixed i18n linting errors in the following files:
- `src/components/widget/SampleModelSelector.vue` - "Upload Model" →
`$t('g.upload')`
- `src/components/topbar/CurrentUserButton.vue` - "user profile" →
`$t('g.currentUser')`
- `src/components/sidebar/tabs/nodeLibrary/NodeHelpPage.vue` - "Loading
help" → `$t('g.loading')`
- `src/components/sidebar/SidebarShortcutsToggleButton.vue` -
"shortcuts.shortcuts" → `$t('shortcuts.shortcuts')`
- `src/components/sidebar/SidebarLogoutIcon.vue` - "sideToolbar.logout"
→ `$t('sideToolbar.logout')`
- `src/components/sidebar/SidebarHelpCenterIcon.vue` - "menu.help" →
`$t('menu.help')`
- `src/components/sidebar/SidebarBottomPanelToggleButton.vue` -
"sideToolbar.labels.console" → `$t('sideToolbar.labels.console')`
- `src/components/load3d/controls/viewer/ViewerCameraControls.vue` -
"fov" → `t('load3d.fov')`
- `src/components/helpcenter/HelpCenterMenuContent.vue` - "Help Center
Menu" and "Recent releases" → `$t()` calls
All raw text strings have been replaced with appropriate i18n
translation keys that already exist in `src/locales/en/main.json`.
## Related Issue
Fixes errors reported in CI job:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18705105609/job/53341658467?pr=5625
This PR aims to help #5625 pass CI/CD checks.
## Test Plan
- All i18n linting errors should be resolved
- No functionality changes - only proper use of i18n system
- Existing translation keys are used from the locale files
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6280-bugfix-fix-intlify-vue-i18n-no-raw-text-linting-errors-2976d73d365081369b43de01486fb409)
by [Unito](https://www.unito.io)
---------
Co-authored-by: GitHub Action <action@github.com>
## Summary
Fixes `trackTemplate` calls to use raw template ID instead of translated
workflow name for analytics tracking.
## Problem
When users load templates with non-English locale, the `workflow_name`
field was being tracked in their language (e.g., "默认工作流" for Chinese
users) instead of English. This makes statistical analysis difficult.
## Changes
- Updated both `trackTemplate` calls in `useTemplateWorkflows.ts` to use
raw `id` instead of translated `workflowName`
- The translated name is still used for display purposes in
`loadGraphData`
**Before:**
```typescript
useTelemetry()?.trackTemplate({
workflow_name: workflowName, // Could be "默认工作流"
template_source: sourceModule
})
```
**After:**
```typescript
useTelemetry()?.trackTemplate({
workflow_name: id, // Always "default"
template_source: sourceModule
})
```
## Testing
- [x] Type checking passes
- [x] Verified translated names still used for display
## Related
Part of comprehensive i18n audit for telemetry tracking. Related to
template metadata English tracking in PR #6304.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6320-bugfix-use-raw-template-ID-for-workflow_name-in-telemetry-tracking-2996d73d365081d8aef3fa2529a10247)
by [Unito](https://www.unito.io)
## Summary
Expands the wait step in `pr-claude-review.yaml` so the
`lewagon/wait-on-check-action` accepts every terminal GitHub conclusion
instead of failing on outcomes like cancelled or failure. After the wait
completes, the `check-status` script still inspects those check runs and
only marks `should-proceed=true` when the tracked jobs finished
successfully.
Fixes what happened here:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18828179272/job/53714488799?pr=6298
## Summary
Updates `SurveyResponses` interface to match actual survey fields 1-to-1
based on analytics requirements.
## Changes
- Remove `team_size` property (no corresponding survey question exists)
- Change `use_case` to `useCase` to match actual survey field name
- Remove `intended_use` property (doesn't exist in actual survey)
- Add `making` field array for content generation type tracking (video,
image, etc.)
This fixes a Mixpanel analytics issue where survey properties weren't
mapping 1-to-1 with actual survey questions, making statistical analysis
difficult.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6314-bugfix-fix-survey-properties-mapping-to-match-actual-survey-data-2996d73d36508158a335e6b73e3e14ef)
by [Unito](https://www.unito.io)
## Summary
Split mask editor structure into smaller files
## Changes
This PR is a prerequisite step for [the issue - refactoring the mask
editor using
Vue](https://github.com/Comfy-Org/ComfyUI_frontend/issues/5956). It
splits the current monolithic maskeditor.ts (about 5700 lines) into
separate files; otherwise, the original single file would be very
difficult to analyze or maintain.
This PR itself does not introduce any Vue, nor should it have any
functional changes or modifications. It's purely a code-level split,
with all related files placed in the maskeditor folder.
The original maskeditor.ts has been renamed to maskeditor.ts.backup for
future reference.
## Review Focus
Since this PR is only for splitting purposes, all logic remains
consistent with the original. Therefore, for any reviewer: any code
logic improvements should happen in the subsequent Vue-based
refactoring, not in this PR.
Following this PR, I will perform a Vue-based refactoring of the mask
editor to align with the frontend's overall Vue architecture and provide
better cloud-related support.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6308-refactor-Split-mask-editor-into-smaller-files-2986d73d36508131937dd43e465a47bd)
by [Unito](https://www.unito.io)
## Summary
Track template metadata in English for analytics regardless of user's
locale to enable consistent statistical analysis.
## Changes
- **What**: Load English [template
index](https://github.com/Comfy-Org/ComfyUI_frontend/tree/main/public/templates)
alongside localized version (cloud builds only)
- **What**: Added `getEnglishMetadata()` method to
`workflowTemplatesStore` that returns English versions of template tags,
category, useCase, models, and license
- **What**: Updated `MixpanelTelemetryProvider` to prefer English
metadata for analytics events, falling back to localized values
## Review Focus
English template fetch only triggers in cloud builds via `isCloud` flag.
Non-cloud builds see no bundle size impact. Method returns null when
English templates unavailable, with fallback to localized data ensuring
analytics continue working in edge cases.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6292-translate-all-analytics-to-English-for-template-metadata-2986d73d365081fdbc21f372aa9bb41e)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
