@ai-ecoverse/slicc 1.39.1 → 1.39.2

package/README.md

@@ -192,7 +192,7 @@ A profile that doesn't exist is an error (`SLICC six's Chrome profile doesn't ex
 - **Live and not debuggable:** slicc stops with exit 1: `six's Chrome is using this profile; close it, or use --browser/--profile to pick another`.
 - **Free** (no lock, or a stale one): slicc launches the browser six used. That is the installed Chromium browser whose version is the profile's `Last Version` (or, without one, the version in `Local State`'s `user_experience_metrics.stability.stats_version`), the first in `slicc browsers`' id order when several match; otherwise Chrome stable. `--browser <id>` overrides it (for `slicc`, the first `--browser`; the others are extras as usual).
 
-**Nothing is written to six's profile.** No seven prefs, no clean-exit marking, no removal of `DevToolsActivePort`, `Singleton*`, the session snapshot or any other file, no extensions added or removed, and no migration. The launch passes only runtime flags, which don't persist: `--remote-debugging-port=0 --user-data-dir=<six's profile> --no-first-run --no-default-browser-check`, the seven flags (left out with `slicc launch --no-seven-flags`), `--headless=new` with `--headless`, and the start page. A `DevToolsActivePort` that was there before the launch is ignored until Chrome writes a new one.
+**Nothing is written to six's profile.** No seven prefs, no clean-exit marking, no removal of `DevToolsActivePort`, `Singleton*`, the session snapshot or any other file, no extensions added or removed, and no migration. The launch passes only runtime flags, which don't persist: `--remote-debugging-port=0 --user-data-dir=<six's profile> --no-first-run --no-default-browser-check`, the throwaway flags only when six's profile is in the temp dir (see [`slicc launch`](#slicc-launch---browser-id---profile-name---url-url---headless---no-seven-flags---json)), the seven flags (left out with `slicc launch --no-seven-flags`), `--headless=new` with `--headless`, and the start page. A `DevToolsActivePort` that was there before the launch is ignored until Chrome writes a new one.
 
 **What does persist** is only what Chrome itself keeps: browsing data from the session, and the seven tab in session restore, so six may reopen that tab the next time it starts Chrome.
 
@@ -480,7 +480,8 @@ Launches a browser with CDP and keeps running until interrupted (Ctrl-C, `SIGINT
   - `slicc/profiles` is never scanned or launched into afterwards.
 - Before the launch, a stale `DevToolsActivePort`, Chrome's `Singleton*` files and the session-restore snapshot are removed, and the last exit is marked clean, so only the start page opens.
 - Before each launch, the seven prefs are merged into the profile's `Default/Preferences`, which is created if missing: `tab_freezing_enabled: false`, `performance_tuning.tab_freezing.enabled: false`, Memory Saver off (`performance_tuning.high_efficiency_mode.state: 0`), and `[*.]sliccy.ai` plus each extra allowed origin's host as tab-discard exceptions. The exceptions go into the list `performance_tuning.tab_discarding.exceptions` (six's form) and into the map `performance_tuning.tab_discarding.exceptions_with_time`, which Chrome 154 reads and shows under "Always keep these sites active". Existing keys, exceptions and timestamps are kept, and a file that already has everything isn't rewritten. A Preferences file that isn't a JSON object is left alone. `--no-seven-flags` skips these prefs too.
-- Chromium flags: `--remote-debugging-port=0 --user-data-dir=<profile> --no-first-run --no-default-browser-check`, the seven flags below, `--headless=new` with `--headless`, then `--url`.
+- Chromium flags: `--remote-debugging-port=0 --user-data-dir=<profile> --no-first-run --no-default-browser-check`, the throwaway flags for a throwaway profile, the seven flags below, `--headless=new` with `--headless`, then `--url`.
+- A throwaway profile is one inside the system temp dir (Go's `os.TempDir()`: `TMPDIR` on macOS and Linux, `TMP` or `TEMP` on Windows; symlinks resolved, case ignored on macOS and Windows). It gets `--use-mock-keychain --password-store=basic` (`browser.ThrowawaySwitches`), so Chrome never asks for the macOS keychain or a Linux password store; without a default keychain, as under a temporary `HOME`, macOS would show "Keychain Not Found". Every other profile, SLICC's and six's included, headless or not, keeps the real keychain, so its saved cookies and passwords stay readable. `browser.Throwaway(dir)` tells which is which.
 - The seven flags keep a seven tab's kernel running while the tab is in the background: `--disable-background-timer-throttling`, `--disable-backgrounding-occluded-windows`, `--disable-renderer-backgrounding`, `--disable-background-tracing`, and `--disable-features=LocalNetworkAccessChecks,LocalNetworkAccessChecksWebSockets,IntensiveWakeUpThrottling,HighEfficiencyModeAvailable,InfiniteTabsFreezing,InfiniteTabsFreezingOnMemoryPressure,CPUMeasurementInFreezingPolicy,MemoryMeasurementInFreezingPolicy,AllowDevtoolsConnectedDiscard`. Chromium ignores feature names it doesn't know. `--no-seven-flags` (`LaunchOptions.NoSevenFlags`) leaves them all out, along with the seven prefs above. Chromium keeps only one `--disable-features` value, so every `--disable-features` from the seven flags and from `LaunchOptions.ExtraArgs` is merged into one switch, in order and without duplicates. The CDP port is read from the profile's `DevToolsActivePort` once `/json/version` answers with the same websocket path (30 s limit). On macOS a browser with a window starts through `open -n -W -a <app> --args …`, so camera and microphone permissions belong to the browser, not the terminal; `--headless` runs the executable directly. A flatpak starts with `flatpak run --filesystem=<profile> <id>`.
 - Electron apps keep their own data and get `--remote-debugging-port=<port>`, the first free port from 9333 up, so they never take 9222–9229. An app that is already running is refused, since a second instance would hand off to it; quit it first. Apps with `debugSupport: "disabled"` are refused.
 - Shutdown: `Browser.close` over CDP; if the browser is still running 5 s later, a signal (`SIGTERM` to the browser's process group and main process; `taskkill /T` on Windows), then after 3 s a kill (`SIGKILL`; `taskkill /F /T`). The browser runs in its own process group (`CREATE_NEW_PROCESS_GROUP` on Windows), so a terminal Ctrl-C reaches only `slicc`.
@@ -1189,7 +1190,7 @@ In the same process, probe ports, dirs and a process list passed in explicitly (
 
 **Port guard.** On CI (`CI` set), or with `SLICC_TEST_PORT_GUARD=1`, `TestMain` holds `127.0.0.1:9222` to `9229` (and `[::1]` where it can) for the whole run, and the run fails if anything connects to them, other than the one test that lends a port to its own fake browser. On CI a port it can't hold fails the run. Off CI it is off by default, so a developer's own Chrome on those ports is never touched; the guarded tests then skip.
 
-On macOS, a headless Chrome started with `HOME` pointed at a temporary dir may never load a page (seen on a developer Mac, not on CI). So on macOS the test that has `slicc` launch Chrome for seven runs it with the real `HOME` and a unique `--profile`, which it deletes afterwards.
+**Real browsers in tests.** The Chrome the harness starts itself is `SLICC_TEST_CHROME` (test-only: the path of a Chrome executable), else the machine's Chrome or Chromium, with the real environment, a temporary profile and `--use-mock-keychain --password-store=basic`. The tests that have `slicc` itself launch a real Chrome run it under a temporary home, where its profiles are throwaway ones. Off CI they never launch the machine's own Chrome: they need `SLICC_TEST_CHROME` set to a Chrome for Testing inside its `.app`, which they link into the temporary home's `Applications` folder on macOS and launch by its id (`chrome-for-testing`), and they skip with a notice without it, or on other systems. On CI they launch the runner's Google Chrome. An older Chrome for Testing can fail the tests that read Chrome's own prefs.
 
 On GitHub's Windows runners the system drive `C:` is slow: with Chrome profiles there, Chrome sometimes waited seconds before a new tab's first request (up to past the 15 s page-load limit) or before exiting (`did not exit`). With them on `D:`, the runner's temp drive, those stalls weren't seen and the suite ran about a quarter faster. So CI points `TEMP` and `TMP` at the runner's temp dir, and the tests' temporary homes and Chrome profiles live there. When a test page doesn't load, the failure says where it stopped: the tab's URL and `readyState`, the resources it fetched, and every request the page server saw.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc",
-  "version": "1.39.1",
+  "version": "1.39.2",
   "description": "SLICC's command line for seven: links a machine's network, compute and browsers to seven over WebRTC",
   "license": "Apache-2.0",
   "repository": {
@@ -18,12 +18,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@ai-ecoverse/slicc-darwin-arm64": "1.39.1",
-    "@ai-ecoverse/slicc-darwin-amd64": "1.39.1",
-    "@ai-ecoverse/slicc-linux-arm64": "1.39.1",
-    "@ai-ecoverse/slicc-linux-amd64": "1.39.1",
-    "@ai-ecoverse/slicc-windows-arm64": "1.39.1",
-    "@ai-ecoverse/slicc-windows-amd64": "1.39.1",
+    "@ai-ecoverse/slicc-darwin-arm64": "1.39.2",
+    "@ai-ecoverse/slicc-darwin-amd64": "1.39.2",
+    "@ai-ecoverse/slicc-linux-arm64": "1.39.2",
+    "@ai-ecoverse/slicc-linux-amd64": "1.39.2",
+    "@ai-ecoverse/slicc-windows-arm64": "1.39.2",
+    "@ai-ecoverse/slicc-windows-amd64": "1.39.2",
     "@ai-ecoverse/slicc-jerk": "^0.15.2"
   }
 }