Fix inactive Browser Use webview attachment on Linux

[tannerpolley]

Summary

• retarget Browser webview recovery exclusively to the current split store, host, and hidden-host renderer assets
• allow an inactive Browser Use conversation to mount its hidden webview while a different conversation owns the visible Browser panel
• continue suppressing the hidden host when the same logical Browser tab is already visible, avoiding duplicate webviews
• report optional drift when any matched recovery asset loses its current production needles
• add patch-report regressions requiring all three recovery descriptors to apply and classifying primary-needle loss as skipped-optional

Root cause

The Browser Use store was synchronizing correctly, but HiddenBrowserUseWebviewHost returned null whenever its conversation was not the active route and any Browser panel was open. Browser automation can legitimately target an inactive synthetic conversation while the visible task owns the panel. In that state the hidden host chunk loaded, but no <webview> was mounted, so neither will-attach-webview nor did-attach-webview fired and the 15-second wait timed out.

The current upstream DMG also split the recovery seams across three renderer assets, so the obsolete combined onboarding-bundle descriptor could no longer restore the store and host halves atomically.

Validation

• node --test scripts/patch-linux-window-ui.test.js — 380/380 passed
• bash tests/scripts_smoke.sh — passed
• independent Standards and Spec review — no remaining code or scope findings
• GitHub CI — Rust/smoke, Debian, RPM, Pacman, and Nix checks passed
• current upstream DMG 26.715.21425 build — passed with an accepted_with_warnings verdict; none of the optional drift entries are Browser recovery descriptors

Remaining gate

The full-restart live Browser attachment validation is still pending. The PR remains draft until a task actively owned by the restarted instance confirms the attachment path end to end.

[Yo-DDV]

Thanks for the patch. I think this still needs one change before it can be treated as fixing the current upstream drift.

The store descriptor added at scripts/patches/core/all-linux/webview/browser-use-attach-recovery/patch.js:17 does not match the upstream DMG that this PR's own Build App Against Upstream DMG job tested. That job passed overall, but its patch summary says linux-browser-use-webview-attach-recovery-store was skipped-optional, and the final acceptance verdict was accepted_with_warnings. So the host half can apply while the store half is still missing, which means the recovery patch is not actually fully restored on the current DMG.

Could you retarget the store descriptor to the real current store chunk and add a regression/report check that catches this case? A green CI job is a bit misleading here because optional patch drift is allowed to pass, but for this PR the skipped store half is the behavior being fixed.

[ilysenko]

Thanks for the update. When this is ready for maintainer review, please remember to mark the pull request as ready for review instead of leaving it in draft.

[ilysenko]

Thanks for the update. The ownership change itself matches the reported inactive-conversation failure, and the previous descriptor issue was fixed for DMG 26.707.72221.

The currently supported DMG is now 26.715.21425, however. Against the current DMG, linux-browser-use-webview-attach-recovery is skipped-optional while only linux-browser-use-hidden-host-ownership applies. The descriptor still targets the obsolete combined onboarding chunk, and the new “current assets” regression test reproduces that older layout rather than the current split store/host assets.

Please rebase onto current main, retarget the recovery descriptors and implementation exclusively to the current DMG layout, remove the obsolete combined-bundle path as required by the current-DMG-only policy, update the patch-report regression with current production shapes, and rerun the upstream build. Please also complete the pending full-restart live Browser attachment validation and mark the PR ready for review.

[PinguuSS]

I reproduced the current-DMG failure independently and prepared the requested retarget on top of current main plus this PR:

PinguuSS@a4ca14d

The current 26.715.21425 renderer has three separate assets:

• store: app-initial~artifact-tab-content.electron~app-main~appgen-settings-page~page~pull-request-r~mxek7o2y-BH5mkLvE.js
• host: app-initial~app-main~pull-request-route~onboarding-page~hotkey-window-thread-page~quick-cha~mo2avlln-Be1pn_Z1.js
• hidden host: browser-sidebar-hidden-browser-use-webview-host-deXVCWnB.js

The commit removes the obsolete combined-bundle descriptor, creates current-only store and host descriptors, updates the host lifecycle fixture to the production shape, and adds a patch-report regression requiring all three descriptors to be applied.

Validation completed against DMG SHA-256 ff459150991612007549270d2d28c5e78cec6bd6ac200a7ada5ed6c031369b87 (26.715.21425, Electron 42.3.0):

• current-DMG isolated build: accepted_with_warnings
• all three Browser recovery descriptors: applied
• second pass over the three generated assets: byte-stable / already applied
• node --check on all three generated assets
• node --test scripts/patch-linux-window-ui.test.js: 377/377
• bash tests/scripts_smoke.sh: passed
• git diff --check: passed

Live side-by-side validation also passed: tabs.new() returned tab 1 immediately, the webview reached will attach -> did attach -> runtime attached -> open wait resolved, and navigation to https://example.com/ returned Example Domain. The installed unpatched build instead disposes/removes the hidden host immediately and times out after 15 seconds.

I restarted the isolated app and confirmed that it relaunched cleanly, but the external test task binding did not re-register with that restarted side-by-side instance. I am therefore not claiming the pending full-restart Browser attachment check as complete; that last check still needs to be run from a task actively owned by the restarted instance.

After rebasing the PR branch onto current main, the commit above should be available to cherry-pick.

[ilysenko]

Thanks for the update. When this is ready for maintainer review, please remember to mark the pull request as ready for review instead of leaving it in draft.