fix(desktop): renderer-lifecycle diagnostics + crash recovery for every window - #83567
Merged
Conversation
…al login windows (#81290 follow-up) @spfcraze's triage review noted the PR description claimed "every BrowserWindow" but the OAuth and portal sign-in windows were not wired: a crashed sign-in renderer leaves the window's promise path never settling, with no trace in desktop.log. Wire both with the same log-only lifecycle diagnostics as the overlay and quick windows — `kind: 'oauth'` and `kind: 'portal'` respectively. Neither window gets crash-reload treatment (a sign-in window that reloads itself mid-auth would be surprising); the lifecycle helper's log-only callback is the exact contract needed here. window-renderer-lifecycle.test.ts: 17/17 pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…re window-reveal (#81290) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Reconcile the salvaged #81533 lifecycle helper with the renderer-log console pipeline that landed in #83535 (the two PRs raced): - window-renderer-lifecycle.ts no longer handles console-message — renderer-log.ts is the single owner (per-window labels, boundary reports). One owner means no double-logged errors on windows wearing both, and OAuth/portal windows (lifecycle-wired for process events) cannot spill third-party page console output into desktop.log. - wake indicator window gets attachRendererConsoleCapture, keeping the console coverage it previously got from the helper. - HUD window (added after the PR branched) gets log-only lifecycle coverage — it was the one renderer window the PR couldn't have known about. - Tests updated: lifecycle helper asserts it attaches NO console-message listener; parser tests live in renderer-log.test.ts.
Contributor
૮ >ﻌ< ა ci reviewran on 126c9f7 — fix(desktop): single-owner console capture + HUD lifecycle c
|
13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Secondary, instance, HUD, quick-entry, overlay, wake, and login windows now log renderer death (
render-process-gone/unresponsive/ main-framedid-fail-load) and recover crashed chat windows under a shared crash-loop budget — a peer window can no longer turn permanently black with zero evidence indesktop.log.Salvage of #81533 by @Enough1122 (all 4 commits cherry-picked with authorship preserved; branch was 114 commits stale), fixing #81290 (@akivavh — three reproduced black secondary windows on Windows, each with empty
render-process-gone/unresponsive/did-fail-loadlookups because nothing was listening).What the contributor built
electron/window-renderer-lifecycle.ts— Electron-free, dependency-injectable per-window lifecycle wiring, installed on everyBrowserWindow:main)killedafter user close is annotated as expected teardown)Follow-up commit (reconciliation with #83535, which landed after the PR branched)
console-messagehandling is removed —renderer-log.ts(from fix(desktop): persist renderer crashes to desktop.log + ban inline render() (React #310 class) #83535) owns it. One owner means no double-logged renderer errors, and OAuth/portal windows (lifecycle-wired for process events) cannot spill third-party page console output — potentially tokens/PII — intodesktop.log.console-messagelistener.Validation
vitestwindow-renderer-lifecycle + wake-indicator + renderer-lognpm run typecheck(renderer + electron + e2e)eslint electron/ src/ --quietFixes #81290
Infographic