Skip to content

WebContentsView lifecycle hardening #1024

Description

@notluquis

Follow-ups from the BrowserView to WebContentsView migration. All of these are low-frequency or latent, but worth tightening now that renderer teardown leans on a manual close() (electron/electron#42884, detach does not destroy the webContents).

Corroborated against master at e050646, except the last item which needs checking in a running build.

  • The focus handlers registered in load() (sessionwindow.ts around lines 194-198) guard only against a missing labView with optional chaining. The invalidate helper added in the same area checks webContents.isDestroyed(), but these focus handlers do not. A closed-but-not-yet-nulled webContents is still a truthy object, so .focus() on it can throw "Object has been destroyed". Adding the same isDestroyed() check keeps the two paths consistent.

  • LabView.labUIReady (labview.ts around line 291) returns a promise that re-arms a 100ms setTimeout until _labUIReady flips true (set at line 79 when the web app signals ready). There is no abort on dispose(), so a session closed or env-switched before JupyterLab reports ready leaves the timer chain running and keeps the disposed LabView's closure alive. It should settle on dispose.

  • The Lab branch of _updateContentView (sessionwindow.ts around line 1203) calls _loadLabView(), which assigns this._labView unconditionally (line 393), without first disposing an existing labView the way the Welcome branch disposes _welcomeView. Today the invariant that _labView is null at that point holds by convention. A guard would make an orphaned WebContentsView impossible if a future path ever reaches it with _labView already set.

  • Needs confirming in a running build: whether closing the session BrowserWindow destroys its WebContentsView children's webContents in Electron 42. labView and welcomeView get an explicit close() because they are rebuilt during the window's lifetime, but the persistent titlebar, progress and env-select views are only torn down when the window closes and do not. If window destruction does not cascade to the child views, each closed session window would leak those renderers. If it does cascade, there is nothing to do here.

Metadata

Metadata

Assignees

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions