morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #1432] [CLOSED] fix(browser): launch verification Chrome without the desktop keyring #2881

New issue

Closed

opened 2026-10-17 21:11:22 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:11:22 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1432
Author: @BaaRai
Created: 10/10/2026
Status: ❌ Closed

Base: main ← Head: fix/browser-lane-basic-password-store

📝 Commits (2)

82338a3 fix(browser): launch verification Chrome without the desktop keyring
aa9cc0a docs(browser): pass --password-store=basic in the manual launch recipe

📊 Changes

4 files changed (+17 additions, -1 deletions)

View changed files

📝 docs/browser-observation.md (+5 -1)
📝 docs/testing.md (+6 -0)
📝 scripts/lib/browser-runtime-fixture-lifecycle.mjs (+3 -0)
📝 scripts/verify-real-browser.mjs (+3 -0)

📄 Description

Summary

Both raw browser-lane launchers now pass --password-store=basic. Verification browsers never read a real keyring, and on Linux a reachable but locked desktop keyring stalls headless Chrome profile startup before the first navigation is issued, which is the real root cause of the empty CDP URLs tracked in #1384.

Problem and expected behavior

On a machine with a desktop session bus whose login keyring is locked (reproduced under WSL with an XFCE session running), every headless Chrome build tried (Kali Chromium 150.0.7871.181, official Chrome-for-Testing 150.0.7871.124 and 154.0.8037.57) reports for the startup page: main-frame URL "" (or ":" on 150), securityOrigin":://, getNavigationHistory [""], DOMSnapshot documents with no documentURL, and storage agents rejecting with frame-not-found. inspect_web_page therefore fails target_not_allowed on main and the whole verify:browser lane is blocked.

The page itself settles on about:blank: Runtime.evaluate inside the page reports location.href === "about:blank" with empty body text, and a startup --log-net-log capture contains zero URL requests and zero proxy events. The navigation is never issued. The keyring daemon shows one pending secret-store prompt object per probe run (/org/freedesktop/secrets/prompt/p1..pN): headless Chrome reaches gnome-keyring over the session bus, the unlock prompt can never be answered, and profile startup stalls before the initial navigation.

An environment bisect isolates it: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus alone, in an otherwise empty environment, reproduces the stall with the same binary and flags; a dead bus path, env -i, or --password-store=basic each load the page normally. Other machines explain the earlier confusion: a desktop that unlocks the keyring at login (CassieFox23's runs in #1384) is clean, and CI runners have no session bus at all, so both see real URLs with the same builds.

Expected behavior: the lane launches browsers it owns, so it must not depend on desktop keyring state. REA already fails closed on an uncommitted frame, which is correct; the launcher should simply not stall in that state.

Change and scope

scripts/verify-real-browser.mjs and scripts/lib/browser-runtime-fixture-lifecycle.mjs gain --password-store=basic next to --headless=new, plus a short docs/testing.md note recording the failure mode. Nothing else changes: no product source, no capture semantics, no fallbacks. PR #1411 is closed in favor of this fix; its target-URL fallback would have authorized capturing a page that never loaded, which is the wrong direction once the browser actually loads pages.

--password-store=basic is inert on Windows and macOS and equivalent to the default on Linux boxes without a session bus, so CI behavior is unchanged.

Contract and boundary impact

not applicable: verification lane launch flags and documentation only; no contract, schema, provider, or capture-path change.

Evidence and regression coverage

Before, on the affected machine (WSL Kali, XFCE session with locked keyring, official CfT 154.0.8037.57 at REA_BROWSER_EXECUTABLE), main fails the lane on the first observation with target_not_allowed. With only this flag added to main's launcher, the complete npm run verify:browser passes: "browser": "Chrome/154.0.8037.57"", "verified": true, zero target_not_allowed occurrences and zero script-metadata failures in the log. The same flag is what the pushed branch runs, and check:fast passes.

The unit suite needs no new coverage: the change is launcher-only and cannot be exercised by the fake CDP fixtures, and the lane itself is the oracle. Issue #1384 carries the full probe matrix, the environment bisect, and the correction of my earlier official-builds claim.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1432 **Author:** [@BaaRai](https://github.com/BaaRai) **Created:** 10/10/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/browser-lane-basic-password-store` --- ### 📝 Commits (2) - [`82338a3`](https://github.com/morluto/rea/commit/82338a367a2c82a0e101f4fd2c3fcd0e6bc671c6) fix(browser): launch verification Chrome without the desktop keyring - [`aa9cc0a`](https://github.com/morluto/rea/commit/aa9cc0a8753d0ef35d1ab9779308719b907568a8) docs(browser): pass --password-store=basic in the manual launch recipe ### 📊 Changes **4 files changed** (+17 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `docs/browser-observation.md` (+5 -1) 📝 `docs/testing.md` (+6 -0) 📝 `scripts/lib/browser-runtime-fixture-lifecycle.mjs` (+3 -0) 📝 `scripts/verify-real-browser.mjs` (+3 -0) </details> ### 📄 Description ## Summary Both raw browser-lane launchers now pass `--password-store=basic`. Verification browsers never read a real keyring, and on Linux a reachable but locked desktop keyring stalls headless Chrome profile startup before the first navigation is issued, which is the real root cause of the empty CDP URLs tracked in #1384. ## Problem and expected behavior On a machine with a desktop session bus whose login keyring is locked (reproduced under WSL with an XFCE session running), every headless Chrome build tried (Kali Chromium 150.0.7871.181, official Chrome-for-Testing 150.0.7871.124 and 154.0.8037.57) reports for the startup page: main-frame URL `""` (or ":" on 150), `securityOrigin":://`, `getNavigationHistory [""]`, `DOMSnapshot` documents with no `documentURL`, and storage agents rejecting with frame-not-found. `inspect_web_page` therefore fails `target_not_allowed` on main and the whole `verify:browser` lane is blocked. The page itself settles on `about:blank`: `Runtime.evaluate` inside the page reports `location.href === "about:blank"` with empty body text, and a startup `--log-net-log` capture contains zero URL requests and zero proxy events. The navigation is never issued. The keyring daemon shows one pending secret-store prompt object per probe run (`/org/freedesktop/secrets/prompt/p1..pN`): headless Chrome reaches gnome-keyring over the session bus, the unlock prompt can never be answered, and profile startup stalls before the initial navigation. An environment bisect isolates it: `DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus` alone, in an otherwise empty environment, reproduces the stall with the same binary and flags; a dead bus path, `env -i`, or `--password-store=basic` each load the page normally. Other machines explain the earlier confusion: a desktop that unlocks the keyring at login (CassieFox23's runs in #1384) is clean, and CI runners have no session bus at all, so both see real URLs with the same builds. Expected behavior: the lane launches browsers it owns, so it must not depend on desktop keyring state. REA already fails closed on an uncommitted frame, which is correct; the launcher should simply not stall in that state. ## Change and scope `scripts/verify-real-browser.mjs` and `scripts/lib/browser-runtime-fixture-lifecycle.mjs` gain `--password-store=basic` next to `--headless=new`, plus a short `docs/testing.md` note recording the failure mode. Nothing else changes: no product source, no capture semantics, no fallbacks. PR #1411 is closed in favor of this fix; its target-URL fallback would have authorized capturing a page that never loaded, which is the wrong direction once the browser actually loads pages. `--password-store=basic` is inert on Windows and macOS and equivalent to the default on Linux boxes without a session bus, so CI behavior is unchanged. ## Contract and boundary impact not applicable: verification lane launch flags and documentation only; no contract, schema, provider, or capture-path change. ## Evidence and regression coverage Before, on the affected machine (WSL Kali, XFCE session with locked keyring, official CfT 154.0.8037.57 at `REA_BROWSER_EXECUTABLE`), main fails the lane on the first observation with `target_not_allowed`. With only this flag added to main's launcher, the complete `npm run verify:browser` passes: `"browser": "Chrome/154.0.8037.57"", "verified": true`, zero `target_not_allowed` occurrences and zero script-metadata failures in the log. The same flag is what the pushed branch runs, and `check:fast` passes. The unit suite needs no new coverage: the change is launcher-only and cannot be exercised by the fake CDP fixtures, and the lane itself is the oracle. Issue #1384 carries the full probe matrix, the environment bisect, and the correction of my earlier official-builds claim. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-17 21:11:22 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-31 01:06:51 +00:00

[PR #2881] [CLOSED] fix(javascript): classify member assignment targets as property writes #5465

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#2881

No description provided.

Rows
Columns