Stop preview loading progress from rerendering the preview

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.

[cursor]

What Changed

• Replaced the 120 ms React state loop used by the preview loading bar with a compositor-driven CSS transform animation.
• Removed useLoadingProgress, so progress animation no longer rerenders PreviewView and its browser surface.
• Moved the URL focus synchronization effect into the named useFocusPreviewUrlInput hook.
• Added a reduced-motion fallback.

Why

React Doctor flagged the loading progress hook's synchronous effect update. A manual ownership trace found the hook running in PreviewView, which made the entire preview tree reconcile roughly eight times per second for a cosmetic animation.

With React Scan enabled, the before recording grows from 1 to 50 parent commits during the measured loading cycle and repeatedly highlights PreviewChromeRow. The after recording stays at 2 commits throughout active loading and reaches 3 only when loading stops, while the progress bar still advances smoothly.

UI Changes

There is no intentional visual change to the loading indicator. Before/after React Scan recordings are included with the automation handoff:

• react_scan_preview_loading_before.mp4
• react_scan_preview_loading_after.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after React Scan recordings for the interaction
• I included a video for animation/interaction changes

Validation: vp check --fix, vp run typecheck, 1,280 web unit tests, and React Doctor changed-file scan (0 diagnostics).

Note

Stop preview loading progress from rerendering the preview

• Replaces the numeric loadProgress-driven progress bar with a CSS-animated bar controlled by a boolean loading state in PreviewChromeRow.tsx.
• Adds a PreviewLoadingProgress component that stays mounted and toggles active/idle CSS classes, animating scaleX between 0.04 and 0.9 via keyframes in index.css.
• Removes the useLoadingProgress hook that simulated asymptotic progress (0→90%, snap to 100%), eliminating the frequent numeric state updates that caused rerenders.
• Respects prefers-reduced-motion by disabling the animation and applying a static transform.

📊 Macroscope summarized 7893cc9. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟢 Lowsrc/index.css:918

The prefers-reduced-motion override disables the active keyframe animation but leaves .preview-loading-progress-idle's 150 ms transform and opacity transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from scaleX(0.9) to scaleX(1). Override the idle transition inside the media query as well.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/index.css around line 918:
The `prefers-reduced-motion` override disables the active keyframe animation but leaves `.preview-loading-progress-idle`'s 150 ms `transform` and `opacity` transitions untouched. When loading finishes, users with reduced motion enabled still see the bar animate from `scaleX(0.9)` to `scaleX(1)`. Override the idle transition inside the media query as well.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing this PR after an automated pass over open pull requests. Abandoned bot draft is also replaced by the merged preview-rendering fix in #7561.