Stop observing chat layout while the pet is disabled

[Bryan Chen (bryanchen-d)]

Summary

Stops ChatPetWidget from observing chat layout while the pet is disabled or not visible in the active window.

Root cause

Stable 1.134 telemetry showed a concentrated Sessions-window runaway:

• 3,966,364 warning occurrences across 10,380 users on August 20
• the largest session emitted 1,399,622 occurrences
• all 7 runaway sessions with pet enablement telemetry had the pet disabled

ChatPetWidget still observed dragBounds, movementBounds, and parent while disabled. Its callback returned immediately, but the no-op nested observer could still become a skipped target when a deeper observer resized one of those ancestors.

The regression fixture uses the real disabled ChatPet and reproduces the observer-depth topology:

• unconditional observation: 1 native loop warning
• visibility-gated observation: 0 warnings

Fix

• Keep the existing ResizeObserver instance.
• Start observing the three layout targets only while the pet is actually visible, enabled, and in the active window.
• Dispose those observations when the pet is disabled, loses focus, or is no longer the latest focused chat.
• Preserve synchronous geometry updates whenever the pet is active.

No frame deferral or enabled-pet behavior change is introduced.

Validation

• compile-client
• 69 ChatPetWidget unit tests
• 6 targeted ResizeObserver Playwright tests
• Native warning positive control
• Pre-commit hygiene

Part of #316501.

Authored with Copilot

[Copilot]

Pull request overview

Stops disabled or inactive chat pets from observing layout bounds, preventing ResizeObserver loop warnings.

Changes:

• Gates layout observations on pet visibility and enablement.
• Adds unit coverage for observation lifecycle.
• Adds a Playwright regression fixture and test.

Show a summary per file

File	Description
chatPetWidget.ts	Manages observations with a MutableDisposable.
chatPetWidget.test.ts	Tests enable/disable observation behavior.
chatWidget.fixture.ts	Adds the disabled-pet regression fixture.
chatPetResizeObserver.spec.ts	Verifies no loop warnings occur.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Balanced

[Bryan Chen (bryanchen-d)]

Additional stable 1.134 impact signal: the broad item + terminal ResizeObserver family is actually two different paths.

Using matched complete rollout windows (1.133 Aug 13–14 vs. 1.134 Aug 20–21):

• ChatTerminalToolProgressPart.handleResize is effectively flat: +2.9% hits, +0.7% users; raw per-session p99 moved from 40 to 39.
• ChatTerminalToolConfirmationSubPart.editor drives the increase: +30.9% hits, +8.3% users; raw per-session p95 moved from 9 to 11 and p99 from 19 to 28.
• Of 1,149,867 confirmation-editor hits in the 1.134 window (including the small progress+confirmation overlap), 1,147,231 / 99.77% had ChatPetWidget.dragBounds in the bounded delivery context.
• Manual runInTerminal preparation exposure rose only about 5%, so increased use alone does not explain the 31% warning increase.

ResizeObserverLoopContext is participant context, not causal attribution, so this does not prove the pet causes every terminal-confirmation warning. It does make this PR the correct first intervention to validate before changing terminal/editor layout timing: the disabled pet observer can become a skipped target even when its callback is a no-op.

Post-merge, I plan to compare commit-bounded Insiders telemetry for both the Sessions family and terminal-confirmation contexts. If the terminal residual remains, the next proof is a multi-confirmation carousel fixture with one-variable observer disconnect/no-op differentials.

Co-authored with Copilot