Resolve merge conflict with updated pricing (.25)

Co-authored-by: webfiltered <176114999+webfiltered@users.noreply.github.com>
Co-authored-by: github-actions <github-actions@github.com>

.claude/commands/create-hotfix-release.md

@@ -0,0 +1,222 @@
+# Create Hotfix Release
+
+This command guides you through creating a patch/hotfix release for ComfyUI Frontend with comprehensive safety checks and human confirmations at each step.
+
+<task>
+Create a hotfix release by cherry-picking commits or PR commits from main to a core branch: $ARGUMENTS
+
+Expected format: Comma-separated list of commits or PR numbers
+Examples: 
+- `abc123,def456,ghi789` (commits)
+- `#1234,#5678` (PRs)
+- `abc123,#1234,def456` (mixed)
+
+If no arguments provided, the command will help identify the correct core branch and guide you through selecting commits/PRs.
+</task>
+
+## Prerequisites
+
+Before starting, ensure:
+- You have push access to the repository
+- GitHub CLI (`gh`) is authenticated
+- You're on a clean working tree
+- You understand the commits/PRs you're cherry-picking
+
+## Hotfix Release Process
+
+### Step 1: Identify Target Core Branch
+
+1. Fetch the current ComfyUI requirements.txt from master branch:
+   ```bash
+   curl -s https://raw.githubusercontent.com/comfyanonymous/ComfyUI/master/requirements.txt | grep "comfyui-frontend-package"
+   ```
+2. Extract the `comfyui-frontend-package` version (e.g., `comfyui-frontend-package==1.23.4`)
+3. Parse version to get major.minor (e.g., `1.23.4` → `1.23`)
+4. Determine core branch: `core/<major>.<minor>` (e.g., `core/1.23`)
+5. Verify the core branch exists: `git ls-remote origin refs/heads/core/*`
+6. **CONFIRMATION REQUIRED**: Is `core/X.Y` the correct target branch?
+
+### Step 2: Parse and Validate Arguments
+
+1. Parse the comma-separated list of commits/PRs
+2. For each item:
+   - If starts with `#`: Treat as PR number
+   - Otherwise: Treat as commit hash
+3. For PR numbers:
+   - Fetch PR details using `gh pr view <number>`
+   - Extract the merge commit if PR is merged
+   - If PR has multiple commits, list them all
+   - **CONFIRMATION REQUIRED**: Use merge commit or cherry-pick individual commits?
+4. Validate all commit hashes exist in the repository
+
+### Step 3: Analyze Target Changes
+
+1. For each commit/PR to cherry-pick:
+   - Display commit hash, author, date
+   - Show PR title and number (if applicable)
+   - Display commit message
+   - Show files changed and diff statistics
+   - Check if already in core branch: `git branch --contains <commit>`
+2. Identify potential conflicts by checking changed files
+3. **CONFIRMATION REQUIRED**: Proceed with these commits?
+
+### Step 4: Create Hotfix Branch
+
+1. Checkout the core branch (e.g., `core/1.23`)
+2. Pull latest changes: `git pull origin core/X.Y`
+3. Display current version from package.json
+4. Create hotfix branch: `hotfix/<version>-<timestamp>`
+   - Example: `hotfix/1.23.4-20241120`
+5. **CONFIRMATION REQUIRED**: Created branch correctly?
+
+### Step 5: Cherry-pick Changes
+
+For each commit:
+1. Attempt cherry-pick: `git cherry-pick <commit>`
+2. If conflicts occur:
+   - Display conflict details
+   - Show conflicting sections
+   - Provide resolution guidance
+   - **CONFIRMATION REQUIRED**: Conflicts resolved correctly?
+3. After successful cherry-pick:
+   - Show the changes: `git show HEAD`
+   - Run validation: `npm run typecheck && npm run lint`
+4. **CONFIRMATION REQUIRED**: Cherry-pick successful and valid?
+
+### Step 6: Create PR to Core Branch
+
+1. Push the hotfix branch: `git push origin hotfix/<version>-<timestamp>`
+2. Create PR using gh CLI:
+   ```bash
+   gh pr create --base core/X.Y --head hotfix/<version>-<timestamp> \
+     --title "[Hotfix] Cherry-pick fixes to core/X.Y" \
+     --body "Cherry-picked commits: ..."
+   ```
+3. Add appropriate labels (but NOT "Release" yet)
+4. PR body should include:
+   - List of cherry-picked commits/PRs
+   - Original issue references
+   - Testing instructions
+   - Impact assessment
+5. **CONFIRMATION REQUIRED**: PR created correctly?
+
+### Step 7: Wait for Tests
+
+1. Monitor PR checks: `gh pr checks`
+2. Display test results as they complete
+3. If any tests fail:
+   - Show failure details
+   - Analyze if related to cherry-picks
+   - **DECISION REQUIRED**: Fix and continue, or abort?
+4. Wait for all required checks to pass
+5. **CONFIRMATION REQUIRED**: All tests passing?
+
+### Step 8: Merge Hotfix PR
+
+1. Verify all checks have passed
+2. Check for required approvals
+3. Merge the PR: `gh pr merge --merge`
+4. Delete the hotfix branch
+5. **CONFIRMATION REQUIRED**: PR merged successfully?
+
+### Step 9: Create Version Bump
+
+1. Checkout the core branch: `git checkout core/X.Y`
+2. Pull latest changes: `git pull origin core/X.Y`
+3. Read current version from package.json
+4. Determine patch version increment:
+   - Current: `1.23.4` → New: `1.23.5`
+5. Create release branch named with new version: `release/1.23.5`
+6. Update version in package.json to `1.23.5`
+7. Commit: `git commit -m "[release] Bump version to 1.23.5"`
+8. **CONFIRMATION REQUIRED**: Version bump correct?
+
+### Step 10: Create Release PR
+
+1. Push release branch: `git push origin release/1.23.5`
+2. Create PR with Release label:
+   ```bash
+   gh pr create --base core/X.Y --head release/1.23.5 \
+     --title "[Release] v1.23.5" \
+     --body "..." \
+     --label "Release"
+   ```
+3. **CRITICAL**: Verify "Release" label is added
+4. PR description should include:
+   - Version: `1.23.4` → `1.23.5`
+   - Included fixes (link to previous PR)
+   - Release notes for users
+5. **CONFIRMATION REQUIRED**: Release PR has "Release" label?
+
+### Step 11: Monitor Release Process
+
+1. Wait for PR checks to pass
+2. **FINAL CONFIRMATION**: Ready to trigger release by merging?
+3. Merge the PR: `gh pr merge --merge`
+4. Monitor release workflow:
+   ```bash
+   gh run list --workflow=release.yaml --limit=1
+   gh run watch
+   ```
+5. Track progress:
+   - GitHub release draft/publication
+   - PyPI upload
+   - npm types publication
+
+### Step 12: Post-Release Verification
+
+1. Verify GitHub release:
+   ```bash
+   gh release view v1.23.5
+   ```
+2. Check PyPI package:
+   ```bash
+   pip index versions comfyui-frontend-package | grep 1.23.5
+   ```
+3. Verify npm package:
+   ```bash
+   npm view @comfyorg/comfyui-frontend-types@1.23.5
+   ```
+4. Generate release summary with:
+   - Version released
+   - Commits included
+   - Issues fixed
+   - Distribution status
+5. **CONFIRMATION REQUIRED**: Release completed successfully?
+
+## Safety Checks
+
+Throughout the process:
+- Always verify core branch matches ComfyUI's requirements.txt
+- For PRs: Ensure using correct commits (merge vs individual)
+- Check version numbers follow semantic versioning
+- **Critical**: "Release" label must be on version bump PR
+- Validate cherry-picks don't break core branch stability
+- Keep audit trail of all operations
+
+## Rollback Procedures
+
+If something goes wrong:
+- Before push: `git reset --hard origin/core/X.Y`
+- After PR creation: Close PR and start over
+- After failed release: Create new patch version with fixes
+- Document any issues for future reference
+
+## Important Notes
+
+- Core branch version will be behind main - this is expected
+- The "Release" label triggers the PyPI/npm publication
+- PR numbers must include the `#` prefix
+- Mixed commits/PRs are supported but review carefully
+- Always wait for full test suite before proceeding
+
+## Expected Timeline
+
+- Step 1-3: ~10 minutes (analysis)
+- Steps 4-6: ~15-30 minutes (cherry-picking)
+- Step 7: ~10-20 minutes (tests)
+- Steps 8-10: ~10 minutes (version bump)
+- Step 11-12: ~15-20 minutes (release)
+- Total: ~60-90 minutes
+
+This process ensures a safe, verified hotfix release with multiple confirmation points and clear tracking of what changes are being released.

.github/workflows/i18n.yaml

@@ -3,6 +3,12 @@ name: Update Locales
 on:
   pull_request:
     branches: [ main, master, dev* ]
+    paths-ignore:
+      - '.github/**'
+      - '.husky/**'
+      - '.vscode/**'
+      - 'browser_tests/**'
+      - 'tests-ui/**'
 
 jobs:
   update-locales:

.github/workflows/release.yaml

@@ -15,6 +15,7 @@ jobs:
       contains(github.event.pull_request.labels.*.name, 'Release')
     outputs:
       version: ${{ steps.current_version.outputs.version }}
+      is_prerelease: ${{ steps.check_prerelease.outputs.is_prerelease }}
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
@@ -24,6 +25,15 @@ jobs:
       - name: Get current version
         id: current_version
         run: echo "version=$(node -p "require('./package.json').version")" >> $GITHUB_OUTPUT
+      - name: Check if prerelease
+        id: check_prerelease
+        run: |
+          VERSION=${{ steps.current_version.outputs.version }}
+          if [[ "$VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+- ]]; then
+            echo "is_prerelease=true" >> $GITHUB_OUTPUT
+          else
+            echo "is_prerelease=false" >> $GITHUB_OUTPUT
+          fi
       - name: Build project
         env:
           SENTRY_DSN: ${{ secrets.SENTRY_DSN }}
@@ -62,9 +72,9 @@ jobs:
             dist.zip
           tag_name: v${{ needs.build.outputs.version }}
           target_commitish: ${{ github.event.pull_request.base.ref }}
-          make_latest: ${{ github.event.pull_request.base.ref == 'main' }}
-          draft: ${{ github.event.pull_request.base.ref != 'main' }}
-          prerelease: false
+          make_latest: ${{ github.event.pull_request.base.ref == 'main' && needs.build.outputs.is_prerelease == 'false' }}
+          draft: ${{ github.event.pull_request.base.ref != 'main' || needs.build.outputs.is_prerelease == 'true' }}
+          prerelease: ${{ needs.build.outputs.is_prerelease == 'true' }}
           generate_release_notes: true
 
   publish_pypi:

.github/workflows/version-bump.yaml

@@ -8,10 +8,12 @@ on:
         required: true
         default: 'patch'
         type: 'choice'
-        options:
-          - patch
-          - minor
-          - major
+        options: [patch, minor, major, prepatch, preminor, premajor, prerelease]
+      pre_release:
+        description: Pre-release ID (suffix)
+        required: false
+        default: ''
+        type: string
 
 jobs:
   bump-version:
@@ -33,19 +35,25 @@ jobs:
       - name: Bump version
         id: bump-version
         run: |
-          npm version ${{ github.event.inputs.version_type }} --no-git-tag-version
+          npm version ${{ github.event.inputs.version_type }} --preid ${{ github.event.inputs.pre_release }} --no-git-tag-version
           NEW_VERSION=$(node -p "require('./package.json').version")
           echo "NEW_VERSION=$NEW_VERSION" >> $GITHUB_OUTPUT
 
+      - name: Format PR string
+        id: capitalised
+        run: |
+          CAPITALISED_TYPE=${{ github.event.inputs.version_type }}
+          echo "capitalised=${CAPITALISED_TYPE@u}" >> $GITHUB_OUTPUT
+
       - name: Create Pull Request
         uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e
         with:
           token: ${{ secrets.PR_GH_TOKEN }}
-          commit-message: '[release] Bump version to ${{ steps.bump-version.outputs.NEW_VERSION }}'
-          title: '${{ steps.bump-version.outputs.NEW_VERSION }}'
+          commit-message: '[release] Increment version to ${{ steps.bump-version.outputs.NEW_VERSION }}'
+          title: ${{ steps.bump-version.outputs.NEW_VERSION }}
           body: |
-            Automated version bump to ${{ steps.bump-version.outputs.NEW_VERSION }}
+            ${{ steps.capitalised.outputs.capitalised }} version increment to ${{ steps.bump-version.outputs.NEW_VERSION }}
           branch: version-bump-${{ steps.bump-version.outputs.NEW_VERSION }}
           base: main
           labels: |
-            Release
+            Release

.husky/pre-commit

@@ -1,5 +1,9 @@
 if [[ "$OS" == "Windows_NT" ]]; then
   npx.cmd lint-staged
+  # Check for unused i18n keys in staged files
+  npx.cmd tsx scripts/check-unused-i18n-keys.ts
 else
   npx lint-staged
+  # Check for unused i18n keys in staged files
+  npx tsx scripts/check-unused-i18n-keys.ts
 fi

CLAUDE.md

@@ -1,8 +1,9 @@
-- use npm run to see what commands are available
+- use `npm run` to see what commands are available
+- For component communication, prefer Vue's event-based pattern (emit/@event-name) for state changes and notifications; use defineExpose with refs only for imperative operations that need direct control (like form.validate(), modal.open(), or editor.focus()); events promote loose coupling and are better for reusable components, while exposed methods are acceptable for tightly-coupled component pairs or when wrapping third-party libraries that require imperative APIs
 - After making code changes, follow this general process: (1) Create unit tests, component tests, browser tests (if appropriate for each), (2) run unit tests, component tests, and browser tests until passing, (3) run typecheck, lint, format (with prettier) -- you can use `npm run` command to see the scripts available, (4) check if any READMEs (including nested) or documentation needs to be updated, (5) Decide whether the changes are worth adding new content to the external documentation for (or would requires changes to the external documentation) at https://docs.comfy.org, then present your suggestion
 - When referencing PrimeVue, you can get all the docs here: https://primevue.org. Do this instead of making up or inferring names of Components
 - When trying to set tailwind classes for dark theme, use "dark-theme:" prefix rather than "dark:"
-- Never add lines to PR descriptions that say "Generated with Claude Code"
+- Never add lines to PR descriptions or commit messages that say "Generated with Claude Code"
 - When making PR names and commit messages, if you are going to add a prefix like "docs:", "feat:", "bugfix:", use square brackets around the prefix term and do not use a colon (e.g., should be "[docs]" rather than "docs:").
 - When I reference GitHub Repos related to Comfy-Org, you should proactively fetch or read the associated information in the repo. To do so, you should exhaust all options: (1) Check if we have a local copy of the repo, (2) Use the GitHub API to fetch the information; you may want to do this IN ADDITION to the other options, especially for reading specific branches/PRs/comments/reviews/metadata, and (3) curl the GitHub website and parse the html or json responses
 - For information about ComfyUI, ComfyUI_frontend, or ComfyUI-Manager, you can web search or download these wikis: https://deepwiki.com/Comfy-Org/ComfyUI-Manager, https://deepwiki.com/Comfy-Org/ComfyUI_frontend/1-overview, https://deepwiki.com/comfyanonymous/ComfyUI/2-core-architecture
@@ -17,7 +18,6 @@
 - Use the Vue 3 Composition API instead of the Options API when writing Vue components. An exception is when overriding or extending a PrimeVue component for compatibility, you may use the Options API.
 - when we are solving an issue we know the link/number for, we should add "Fixes #n" (where n is the issue number) to the PR description.
 - Never write css if you can accomplish the same thing with tailwind utility classes
-- Use setup() function for component logic
 - Utilize ref and reactive for reactive state
 - Implement computed properties with computed()
 - Use watch and watchEffect for side effects
@@ -27,14 +27,12 @@
 - Use Tailwind CSS for styling
 - Leverage VueUse functions for performance-enhancing styles
 - Use lodash for utility functions
-- Use TypeScript for type safety
 - Implement proper props and emits definitions
 - Utilize Vue 3's Teleport component when needed
 - Use Suspense for async components
 - Implement proper error handling
 - Follow Vue 3 style guide and naming conventions
-- Use Vite for fast development and building
-- Use vue-i18n in composition API for any string literals. Place new translation entries in src/locales/en/main.json.
+- IMPORTANT: Use vue-i18n for ALL user-facing strings - no hard-coded text in services/utilities. Place new translation entries in src/locales/en/main.json
 - Avoid using `@ts-expect-error` to work around type issues. We needed to employ it to migrate to TypeScript, but it should not be viewed as an accepted practice or standard.
 - DO NOT use deprecated PrimeVue components. Use these replacements instead:
   * `Dropdown` → Use `Select` (import from 'primevue/select')
@@ -54,3 +52,7 @@
   - Templates: `api.fileURL('/templates/default.json')`
   - Extensions: `api.fileURL(extensionPath)` for loading JS modules
   - Any static assets that exist in the public directory
+- When implementing code that outputs raw HTML (e.g., using v-html directive), always ensure dynamic content has been properly sanitized with DOMPurify or validated through trusted sources. Prefer Vue templates over v-html when possible.
+- For any async operations (API calls, timers, etc), implement cleanup/cancellation in component unmount to prevent memory leaks
+- Extract complex template conditionals into separate components or computed properties
+- Error messages should be actionable and user-friendly (e.g., "Failed to load data. Please refresh the page." instead of "Unknown error")

VUE_NODE_MIGRATION_PLAN.md

@@ -1,401 +0,0 @@
-# Vue Node Migration Plan
-
-## Executive Summary
-
-This plan outlines a phased migration from LiteGraph canvas rendering to Vue-based DOM rendering for ComfyUI nodes. Vue-based nodes allows access to component libraries (PrimeVue) and CSS frameworks, which increases iteration speed significantly. The migration preserves LiteGraph as the source of truth for graph logic while leveraging Vue components for rich, accessible node interfaces. Increased development speed will facilitate next gen UI/UX changes: .
-
-## Goals and Objectives
-
-### Primary Goals
-
-- Enable rapid UI iteration with Vue's component model, PrimeVue, and CSS frameworks
-- Maintain performance for workflows with 100+ nodes
-- Preserve extension compatibility (90%+ without changes)
-- Improve developer experience
-
-### Success Metrics
-
-- New components implementable in <1 hour (vs. current DOM manipulation)
-- Performance regression <25% for 100-node workflows
-- 90% of existing extensions work unmodified
-- 3x faster UI development iteration
-- Memory usage within 1.5x of canvas-only approach
-
-### Non-Goals
-
-- Complete canvas replacement (connections remain canvas-rendered)
-- Mobile/touch optimization (separate initiative)
-- Workflow format changes (must remain compatible)
-- Extension API redesign (compatibility layer only)
-
-### Definition of Done
-
-- All core node types render via Vue components
-- Canvas handles only connections and viewport
-- Performance benchmarks meet targets
-- Extension compatibility layer tested with top 20 extensions
-- Migration guide published for extension developers whose extensions are broken by the migration
-- Feature flag allows instant rollback
-
-## Architecture Overview
-
-### Current State
-
-LiteGraph with mixed rendering approaches:
-
-- **Canvas**: node bodies, connections, grid, selection
-- **Widgets**: Three types coexist:
-  - Canvas widgets (drawn in 2D context)
-  - DOM widgets (manually positioned HTML elements)
-  - Vue widgets (components positioned via DOM)
-- **Events**: Canvas handles most interactions, delegates to widgets
-- **State**: Stored in LiteGraph node/graph objects
-
-### Target State
-
-Hybrid rendering with clear separation:
-
-- **Canvas**: connections, grid, viewport pan/zoom, selection rectangles
-- **DOM (Vue)**: all node contents and widgets unified as Vue components
-- **Transform Pane**: single Vue-managed container synchronized with canvas transforms
-- **State**: LiteGraph remains source of truth, Vue observes changes
-
-### Hybrid Approach
-
-During migration, both systems coexist:
-
-- Feature flag controls Vue rendering per node type
-- Canvas nodes and Vue nodes can connect normally
-- Shared event system handles both rendering modes
-- Progressive migration allows testing at each phase
-
-## Technical Design
-
-### Component Architecture
-
-```
-GraphCanvas.vue
-└── TransformPane.vue (synchronized with canvas transforms)
-    └── LGraphNode.vue (v-for visible nodes)
-        ├── NodeHeader.vue (title, controls)
-        ├── NodeSlots.vue (input/output connection points)
-        │   ├── InputSlot.vue (connection target)
-        │   └── OutputSlot.vue (connection source)
-        ├── NodeWidgets.vue (parameter controls)
-        │   └── [Widget components rendered here]
-        │       ├── NumberWidget.vue
-        │       ├── StringWidget.vue
-        │       ├── ComboWidget.vue
-        │       └── [etc...]
-        └── NodeContent.vue (custom content area)
-```
-
-Slots = connection points for node edges
-Widgets = UI controls for node parameters
-
-### State Management
-
-- **One-way data flow**: LiteGraph → Vue components (props down, events up)
-  - Widget values flow from LiteGraph to Vue as props
-  - User interactions emit events that update LiteGraph
-  - Updated values flow back to Vue, completing the cycle
-- **LiteGraph as source of truth**: All node/graph state remains in LiteGraph
-- **Vue as view layer**: Components observe and reflect LiteGraph state
-
-### Event System
-
-- **Canvas events**: Pan, zoom, connection dragging, box selection
-- **DOM events**: Node interactions, widget inputs, context menus
-- **Transform sync**: No coordinate mapping needed - transforms handle positioning
-- **(Future) Event delegation**: Single listener on TransformPane for efficiency
-- **(Future) Touch handling**: Unified pointer events for mouse/touch consistency
-
-### Positioning Strategy: CSS Transforms
-
-For positioning nodes in the DOM, we'll use CSS transforms rather than absolute positioning with top/left. This decision is based on significant performance benefits validated by industry leaders (React Flow, Excalidraw, tldraw, Figma).
-
-#### Core Implementation
-
-```vue
-<!-- TransformPane synchronized with canvas -->
-<div class="transform-pane" :style="{ transform: `scale(${zoom}) translate(${panX}px, ${panY}px)` }">
-  <!-- Individual nodes use simple translate -->
-  <div v-for="node in visibleNodes" 
-       :style="{ transform: `translate(${node.x}px, ${node.y}px)` }">
-</div>
-```
-
-#### Key Optimizations
-
-- **CSS Containment**: `contain: layout style paint` isolates node rendering
-- **GPU Acceleration**: `will-change: transform` during interactions only
-- **Batched Updates**: CSS custom properties for efficient updates
-
-#### Handling PrimeVue Overlays
-
-Portal strategy for components with fixed positioning:
-
-```vue
-<Teleport to="body" v-if="showOverlay">
-  <Popover :style="{ position: 'fixed', left: `${coords.x}px`, top: `${coords.y}px` }">
-</Teleport>
-```
-
-#### Alternative Approaches
-
-| Approach | Performance | Complexity | Use Case |
-|----------|------------|------------|-----------|
-| **CSS Transforms** | Excellent (GPU) | Medium | ✅ Our choice |
-| **Absolute Position** | Poor (reflow) | Low | Small node counts |
-| **Canvas Rendering** | Best | High | Not compatible with Vue |
-| **SVG** | Good | Medium | Better for connections |
-
-## Migration Strategy
-
-### Phase 1: Widget Migration
-
-For each widget:
-
-- Create a new Vue component for the widget, using the API defined here: https://www.notion.so/drip-art/Widget-Componet-APIs-2126d73d365080b0bf30f241c09dd756
-- If the widget existed before, alias the constructor to the new component (q: why not just replace entirely? any reason to keep the old constructor?)
-- If the widget is new, create a new constructor for the widget and add to widgets.ts
-- Implement the existing widget interface in the new component (i.e., create Vue-compatible mappings of the LG widget's props and events)
-- Avoid components that use things like fixed positioning, teleport, `fill-available`, in the widget component (e.g., PrimeVue's Popover, Tooltip, Select) as they will require a portal strategy to work with transforms
-
-### Phase 2: Node Migration
-
-- Create a new Vue component for the node
-- [maybe later] Create conditional render for LOD, distance cull, and viewport cull
-- Implement the existing node interface in the new node component (i.e., create Vue-compatible mappings of the LG node's props and events)
-
-### Phase 3: Transform Pane
-
-- Create the transform pane
-- Synchronize the transform pane with the canvas transforms
-- Use `transform-origin` to position the transform pane in accordance with the canvas
-- Use `will-change: transform` and verify with DevTools that nodes are on a single layer and not being promoted
-  - NOTE: in future, we need to actively prevent layer promotion (see promotion conditions: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/graphics/compositing_reasons.h;l=18;drc=4e8e81f6eeb6969973f3ec97132d80339b92d227)
-
-### Phase 4: Interaction System
-
-- Map all existing events from previous interface
-  - Map all lifecycle hooks
-- Add event delegation for transform pane events
-- Restrict touch events to the transform pane
-- For any event (except those affecting the entire transform pane) that affects compositing (e.g., moving nodes, resizing nodes), batch in RAF
-
-### Phase 5: Portals
-
-- Create a portal component that can be used to render components that use fixed positioning, teleport, `fill-available`, etc.
-
-### Phase 6: Performance Optimizations
-
-- Create baseline performance metrics
-- For each optimization, test and iterate while comparing against baseline:
-  - Implement viewport culling or LOD
-    - It may be less efficient to cull nodes if we are only doing compositing and not actually recalc and reflow. This must be manually verified. In any case, there is still probably a very large threshold to implement viewport culling by, but it may be the case that it's not worth the effort to do.
-  - Implement distance culling and LOD
-  - (optional) Implement virtualization, prefetching, prerendering, preloading, preconnecting if still necessary
-
-### Phase 7: Extension Migration
-
-- Review all of the most common touch points from extension space
-- Determine if any compatibility mappings are still needed, then implement them and add to public API
-- Gradually test with more and more frontend extensions
-
-## Performance
-
-### Benchmarking Strategy
-
-- Use existing performance wrapper playwright testing strategy created in https://www.notion.so/drip-art/Analyze-Performance-Impact-of-only-using-Vue-widgets-20b6d73d36508080a14cea0b8dce7073?source=copy_link#20d6d73d365080409a8ccc68f501284e
-  - Or, a subset of it
-
-### Optimization Techniques
-
-- Use `will-change: transform` and `transform: translateZ(0)` to force GPU acceleration
-- Use `contain: layout style paint` to tell the browser this element won't affect outside layout
-- Use `transform-origin` to position the transform pane in accordance with the canvas
-- ~~Use `transform: translate3d(round(var(--x), 1px), round(var(--y), 1px), 0)` to snap to pixels during non-animated states~~
-
-### Scaling Targets
-
-- 256 nodes full LOD
-- 1000 nodes culled
-
-### Production Monitoring
-
-For desktop users who have consented to telemetry:
-
-- **Mixpanel Events**: Track migration feature adoption and performance metrics
-  - Node rendering time percentiles (p50, p90, p99)
-  - Frame rate during node interactions
-  - Memory usage with different node counts
-- **Sentry Performance**: Monitor real-world performance regressions
-  - Transaction traces for node operations
-  - Custom performance marks for render phases
-  - Error rates specific to Vue node rendering
-
-## Extension Compatibility Plan
-
-### Migration Guide
-
-Comprehensive migration documentation will be published at https://docs.comfy.org including:
-
-- Step-by-step migration instructions for common patterns
-- Code examples for converting canvas widgets to Vue components
-- API compatibility reference
-- Performance optimization guidelines
-
-### Compatibility Layer
-
-[Placeholder: Supporting both rendering modes]
-
-### Deprecation Timeline
-
-[Placeholder: List things that will be deprecated fully]
-
-### Developer Communication
-
-- **Email notifications** via existing developer mailing list
-- **Discord announcements** in dedicated devrel channel
-- **Automated PRs** to affected repositories (if breaking changes required)
-
-## Testing
-
-### Testing Strategy
-
-#### Component Tests
-
-- Create component tests for each widget and node
-
-#### Integration Tests
-
-- Create integration tests for canvas and transform pane synchronization
-
-#### Performance Tests
-
-maybe
- 
-### Migration of Existing Test Suites
-
-#### Unit Tests
-
-[Placeholder: strategy for migrating unit tests]
-
-
-#### Browser Tests
-
-[Placeholder: strategy for migrating browser tests]
-
-## Risk Mitigation
-
-### Technical Risks
-
-#### Performance Degradation
-
-- **Risk**: DOM nodes significantly slower than canvas rendering
-- **Mitigation**: Aggressive viewport culling, CSS containment, GPU acceleration
-- **Monitoring**: Automated performance benchmarks on each PR
-
-#### Memory Usage
-
-- **Risk**: 1000+ DOM nodes consume excessive memory
-- **Mitigation**: Component pooling, virtualization for large workflows
-- **Detection**: Memory profiling in browser tests
-
-#### Extension Breaking Changes
-
-- **Risk**: Popular extensions stop working
-- **Mitigation**: Compatibility layer maintaining critical APIs
-- **Testing**: Top 20 extensions tested before each phase
-
-#### State Synchronization Bugs
-
-- **Risk**: LiteGraph and Vue state diverge
-- **Mitigation**: Strict one-way data flow, comprehensive event testing
-- **Prevention**: State invariant checks in development mode
-
-### Rollback Plan
-
-1. **Feature flag**: `enable_vue_nodes` setting (default: false)
-2. **Gradual rollout**: Enable for specific node types first
-3. **Quick revert**: Single flag disables all Vue rendering
-4. **Data compatibility**: No changes to workflow format ensures backward compatibility
-
-## Timeline and Milestones
-
-### Week 1
-
-[Placeholder: Initial milestones]
-
-### Week 2
-
-[Placeholder: Mid-term milestones]
-
-### Week 3
-
-[Placeholder: Final milestones]
-
-## Open Questions
-
-### Widget Constructor Aliasing
-
-- Why keep old constructors vs. full replacement? (Phase 1, line 53)
-- Is this for backwards compatibility with existing extensions?
-
-### Viewport Culling Efficiency
-
-- At what node count does viewport culling become beneficial? (Phase 6, line 89)
-- Does the compositing-only benefit outweigh the Vue mount/unmount cost?
-
-### Extension Compatibility
-
-- How much of extension surface area to attempt to cover in compatibility layer?
-- Which extension APIs are most critical to preserve?
-
-### Transform Pane Synchronization
-
-- How to handle canvas zoom/pan events?
-- Should transform sync be RAF-batched or immediate?
-
-### Event Delegation
-
-- Which events stay on canvas vs. move to DOM?
-  - **Option A**: Canvas handles all drag/pan, DOM handles clicks/inputs
-  - **Option B**: DOM handles everything except connection dragging
-    - *Note: This option provides the best UX - users expect DOM elements to be fully interactive while keeping complex connection logic in canvas*
-  - **Option C**: Context-aware delegation based on interaction type
-
-### LOD (Level of Detail) System
-
-- What defines each LOD level?
-  - **High**: Full widgets and styling
-  - **Medium**: Simplified widgets, reduced effects?
-  - **Low**: Title and connections only?
-- Transition triggers: zoom level, node count, or performance metrics?
-  - *Note: Zoom level as primary trigger is most predictable for users, with node count as override for performance protection*
-
-### Interaction System Migration
-
-- How to maintain gesture consistency between canvas and DOM nodes?
-- Multi-select behavior across rendering boundaries?
-
-## Appendices
-
-### A. Prototype Learnings
-
-Detailed findings and discoveries from process of developing Vue widgets and Vue nodes prototype (in vue-node-test branch)
-
-- Constructing components easy, difficulty is performance and compatibility
-
-### B. Performance and Browser Rendering
-
-- https://www.notion.so/drip-art/Analyze-Performance-Impact-of-only-using-Vue-widgets-20b6d73d36508080a14cea0b8dce7073?source=copy_link#20d6d73d365080409a8ccc68f501284e
-- https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/graphics/compositing_reasons.h;l=18;drc=4e8e81f6eeb6969973f3ec97132d80339b92d227
-- https://webperf.tips/tip/browser-rendering-pipeline/
-- https://webperf.tips/tip/layers-and-compositing/
-- https://webperf.tips/tip/layout-thrashing/
-
-### C. API Design
-
-- https://www.notion.so/drip-art/Widget-Componet-APIs-2126d73d365080b0bf30f241c09dd756

browser_tests/README.md

@@ -29,6 +29,16 @@ A template with helpful information can be found in `.env_example`.
 ### Multiple Tests
 If you are running Playwright tests in parallel or running the same test multiple times, the flag `--multi-user` must be added to the main ComfyUI process.
 
+### Release API Mocking
+By default, all tests mock the release API (`api.comfy.org/releases`) to prevent release notification popups from interfering with test execution. This is necessary because the release notifications can appear over UI elements and block test interactions.
+
+To test with real release data, you can disable mocking:
+```typescript
+await comfyPage.setup({ mockReleases: false });
+```
+
+For tests that specifically need to test release functionality, see the example in `tests/releaseNotifications.spec.ts`.
+
 ## Running Tests
 
 There are multiple ways to run the tests:

browser_tests/fixtures/ComfyPage.ts

@@ -268,8 +268,34 @@ export class ComfyPage {
     return this._history
   }
 
-  async setup({ clearStorage = true }: { clearStorage?: boolean } = {}) {
+  async setup({
+    clearStorage = true,
+    mockReleases = true
+  }: {
+    clearStorage?: boolean
+    mockReleases?: boolean
+  } = {}) {
     await this.goto()
+
+    // Mock release endpoint to prevent changelog popups
+    if (mockReleases) {
+      await this.page.route('**/releases**', async (route) => {
+        const url = route.request().url()
+        if (
+          url.includes('api.comfy.org') ||
+          url.includes('stagingapi.comfy.org')
+        ) {
+          await route.fulfill({
+            status: 200,
+            contentType: 'application/json',
+            body: JSON.stringify([])
+          })
+        } else {
+          await route.continue()
+        }
+      })
+    }
+
     if (clearStorage) {
       await this.page.evaluate((id) => {
         localStorage.clear()
@@ -1086,7 +1112,7 @@ export const comfyPageFixture = base.extend<{
   },
   comfyMouse: async ({ comfyPage }, use) => {
     const comfyMouse = new ComfyMouse(comfyPage)
-    use(comfyMouse)
+    await use(comfyMouse)
   }
 })
 

browser_tests/tests/groupNode.spec.ts

@@ -17,11 +17,11 @@ test.describe('Group Node', () => {
       await libraryTab.open()
     })
 
-    test('Is added to node library sidebar', async ({ comfyPage }) => {
+    test.skip('Is added to node library sidebar', async ({ comfyPage }) => {
       expect(await libraryTab.getFolder('group nodes').count()).toBe(1)
     })
 
-    test('Can be added to canvas using node library sidebar', async ({
+    test.skip('Can be added to canvas using node library sidebar', async ({
       comfyPage
     }) => {
       const initialNodeCount = await comfyPage.getGraphNodesCount()
@@ -34,7 +34,7 @@ test.describe('Group Node', () => {
       expect(await comfyPage.getGraphNodesCount()).toBe(initialNodeCount + 1)
     })
 
-    test('Can be bookmarked and unbookmarked', async ({ comfyPage }) => {
+    test.skip('Can be bookmarked and unbookmarked', async ({ comfyPage }) => {
       await libraryTab.getFolder(groupNodeCategory).click()
       await libraryTab
         .getNode(groupNodeName)
@@ -61,7 +61,7 @@ test.describe('Group Node', () => {
       ).toHaveLength(0)
     })
 
-    test('Displays preview on bookmark hover', async ({ comfyPage }) => {
+    test.skip('Displays preview on bookmark hover', async ({ comfyPage }) => {
       await libraryTab.getFolder(groupNodeCategory).click()
       await libraryTab
         .getNode(groupNodeName)
@@ -95,7 +95,7 @@ test.describe('Group Node', () => {
     )
   })
 
-  test('Displays tooltip on title hover', async ({ comfyPage }) => {
+  test.skip('Displays tooltip on title hover', async ({ comfyPage }) => {
     await comfyPage.setSetting('Comfy.EnableTooltips', true)
     await comfyPage.convertAllNodesToGroupNode('Group Node')
     await comfyPage.page.mouse.move(47, 173)
@@ -104,7 +104,7 @@ test.describe('Group Node', () => {
     await expect(comfyPage.page.locator('.node-tooltip')).toBeVisible()
   })
 
-  test('Manage group opens with the correct group selected', async ({
+  test.skip('Manage group opens with the correct group selected', async ({
     comfyPage
   }) => {
     const makeGroup = async (name, type1, type2) => {
@@ -165,7 +165,7 @@ test.describe('Group Node', () => {
     expect(visibleInputCount).toBe(2)
   })
 
-  test('Reconnects inputs after configuration changed via manage dialog save', async ({
+  test.skip('Reconnects inputs after configuration changed via manage dialog save', async ({
     comfyPage
   }) => {
     const expectSingleNode = async (type: string) => {

browser_tests/tests/releaseNotifications.spec.ts

@@ -0,0 +1,133 @@
+import { expect } from '@playwright/test'
+
+import { comfyPageFixture as test } from '../fixtures/ComfyPage'
+
+test.describe('Release Notifications', () => {
+  test.beforeEach(async ({ comfyPage }) => {
+    await comfyPage.setSetting('Comfy.UseNewMenu', 'Top')
+  })
+
+  test('should show help center with release information', async ({
+    comfyPage
+  }) => {
+    // Mock release API with test data instead of empty array
+    await comfyPage.page.route('**/releases**', async (route) => {
+      const url = route.request().url()
+      if (
+        url.includes('api.comfy.org') ||
+        url.includes('stagingapi.comfy.org')
+      ) {
+        await route.fulfill({
+          status: 200,
+          contentType: 'application/json',
+          body: JSON.stringify([
+            {
+              id: 1,
+              project: 'comfyui',
+              version: 'v0.3.44',
+              attention: 'medium',
+              content:
+                '## New Features\n\n- Added awesome feature\n- Fixed important bug',
+              published_at: new Date().toISOString()
+            }
+          ])
+        })
+      } else {
+        await route.continue()
+      }
+    })
+
+    // Setup with release mocking disabled for this test
+    await comfyPage.setup({ mockReleases: false })
+
+    // Open help center
+    const helpCenterButton = comfyPage.page.locator('.comfy-help-center-btn')
+    await helpCenterButton.waitFor({ state: 'visible' })
+    await helpCenterButton.click()
+
+    // Verify help center menu appears
+    const helpMenu = comfyPage.page.locator('.help-center-menu')
+    await expect(helpMenu).toBeVisible()
+
+    // Verify "What's New?" section shows the release
+    const whatsNewSection = comfyPage.page.locator('.whats-new-section')
+    await expect(whatsNewSection).toBeVisible()
+
+    // Should show the release version
+    await expect(
+      whatsNewSection.locator('text=Comfy v0.3.44 Release')
+    ).toBeVisible()
+
+    // Close help center by dismissable mask
+    await comfyPage.page.click('.help-center-backdrop')
+    await expect(helpMenu).not.toBeVisible()
+  })
+
+  test('should not show release notifications when mocked (default behavior)', async ({
+    comfyPage
+  }) => {
+    // Use default setup (mockReleases: true)
+    await comfyPage.setup()
+
+    // Open help center
+    const helpCenterButton = comfyPage.page.locator('.comfy-help-center-btn')
+    await helpCenterButton.waitFor({ state: 'visible' })
+    await helpCenterButton.click()
+
+    // Verify help center menu appears
+    const helpMenu = comfyPage.page.locator('.help-center-menu')
+    await expect(helpMenu).toBeVisible()
+
+    // Verify "What's New?" section shows no releases
+    const whatsNewSection = comfyPage.page.locator('.whats-new-section')
+    await expect(whatsNewSection).toBeVisible()
+
+    // Should show "No recent releases" message
+    await expect(
+      whatsNewSection.locator('text=No recent releases')
+    ).toBeVisible()
+
+    // Should not show any popups or toasts
+    await expect(comfyPage.page.locator('.whats-new-popup')).not.toBeVisible()
+    await expect(
+      comfyPage.page.locator('.release-notification-toast')
+    ).not.toBeVisible()
+  })
+
+  test('should handle release API errors gracefully', async ({ comfyPage }) => {
+    // Mock API to return an error
+    await comfyPage.page.route('**/releases**', async (route) => {
+      const url = route.request().url()
+      if (
+        url.includes('api.comfy.org') ||
+        url.includes('stagingapi.comfy.org')
+      ) {
+        await route.fulfill({
+          status: 500,
+          contentType: 'application/json',
+          body: JSON.stringify({ error: 'Server error' })
+        })
+      } else {
+        await route.continue()
+      }
+    })
+
+    // Setup with release mocking disabled
+    await comfyPage.setup({ mockReleases: false })
+
+    // Open help center
+    const helpCenterButton = comfyPage.page.locator('.comfy-help-center-btn')
+    await helpCenterButton.waitFor({ state: 'visible' })
+    await helpCenterButton.click()
+
+    // Verify help center still works despite API error
+    const helpMenu = comfyPage.page.locator('.help-center-menu')
+    await expect(helpMenu).toBeVisible()
+
+    // Should show no releases due to error
+    const whatsNewSection = comfyPage.page.locator('.whats-new-section')
+    await expect(
+      whatsNewSection.locator('text=No recent releases')
+    ).toBeVisible()
+  })
+})