Commit graph

11 commits

Author SHA1 Message Date
Local Dev
2e42783dfe fix(theseus/screenshot): 0.2.4 — deliver capture via addon storage, not a cross-origin file://
Blank editor + broken buttons root cause: index.js was writing the
capture to <userData>/addons-data/screenshot-scratch/<name>.png and
passing "?src=file://<that path>" to editor.html. The editor lives at
file:///<userData>/addons/screenshot/editor.html — different directory
tree under file://. Chromium's file:// origin policy treats those as
different origins and quietly refuses the <img> load, so init()'s
loadImage() rejects, the canvas never gets an image, and every tool
after that operates on a still-empty 300×150 default canvas — the
tools appear to work but produce no visible output because the base
image never landed. The sidebar version we replaced set
`previewImg.src = dataUrl` (a base64 data URL) directly, which has no
origin and just worked; the tab version regressed by adding the file
hop.

Fix keeps the scratch file for the recent-captures ring but hands
the raw capture through the add-on's per-add-on kv store
(`__pending` key). Same store, same origin scoping, no
cross-directory read: index.js writes via api.storage.set from main;
editor.js reads via window.silentmode.storage.get through the tab
preload (packaged since 0.3.27). Fallback path retained for
"openRecent" callers still passing ?src=… — those will need their
own fix in a follow-up.

Bumped to 0.2.4 and signed for the OTA endpoint — first real
independent add-on ship: no Theseus release needed to fix this,
0.3.27 installs pick up 0.2.4 via the boot-time signed-update poll.
2026-09-08 12:57:46 +02:00
Local Dev
638aa4d326 feat(theseus/addons): CDP capture + editor Discard + manual update controls
Three tied-together fixes:

1) captureTab moves from WebContents.capturePage() to CDP
   Page.captureScreenshot for every mode (visible / full / region).
   Blank-screenshot symptom: after a toolbar-menu selection, the OS
   popup teardown left the tab view marked occluded for a few frames
   on some Windows setups, so capturePage() snapshotted a
   stale/transparent frame at the correct dimensions — no 0x0, no
   retry hit. CDP forces a fresh composite regardless of occlusion
   state (same path the "Full page" mode was already using) and
   returns a base64 PNG directly; PNG dimensions come out of the
   IHDR chunk (bytes 16-24). Attach only when nothing else has, and
   detach after only if WE attached, so an open DevTools stays
   attached.

2) Editor gets a Discard button. Toolbar picks up an "×" glyph next
   to Save/Copy that closes the editor tab and drops the working
   screenshot. Top-level Escape now falls through the same path
   after unwinding an in-flight text placement or crop rectangle. A
   new "addon-tab-close" IPC lets an add-on's own tab close itself
   (main matches the sender's webContents id against the tab list,
   so a page can only close its own tab); window.silentmode.closeTab()
   exposes it from addon-tab-preload.js.

3) Manual update controls in Settings > Extensions. New "Check for
   updates" button at the top of the Extensions surface calls the
   same signed-update polling the boot timer runs; the result is
   surfaced inline ("All extensions are up to date" / "N updates
   staged; restart Theseus to apply"). A "Pending updates" box
   below lists what's in <userData>/addons-updates-staged/ so the
   user knows what will be promoted on next restart.

Toolbar-menu popup settle bumped from 120 ms to 250 ms with an
explicit win.focus() in the popup close callback — the previous
window wasn't enough on slower Windows setups. CDP capture no longer
depends on this delay anyway, but the settle still helps any add-on
that does DOM work in its click handler before capture.

Screenshot add-on bumped 0.2.2 → 0.2.3 (Discard button; capture
fixes come from the host, not the add-on).
2026-09-08 02:27:36 +02:00
Local Dev
7806e3f31c fix(theseus/light): sweep hardcoded acid → var(--acid), Theseus button uses BCH dark
Two follow-ups on the light-mode acid work:

1) Every hardcoded #d6ff3d and rgba(214,255,61,X) in the browser
   chrome and every addon panel now goes through var(--acid), so the
   light-mode BCH-teal (#0AC18E) takes effect everywhere — not just
   where var(--acid) was already used. Hex-with-alpha (#d6ff3d55 etc.)
   converts to color-mix(); rgba() converts to rgb(from var(--acid)…)
   for the same alpha with the current --acid hue. Chromium 128+
   supports both. Files touched: chrome / settings / error / home /
   approval / bchwallet / siawallet / screenshot (html + css).
   Screenshot editor.js's #d6ff3d stays — that's the drawing colour
   swatch, not UI chrome.

2) The Theseus button (.logo) and update chip (.upchip) become dark
   BCH-navy chips (#253A49 background, #F8FDFF text) in light mode.
   Previously the .logo hardcoded #d6ff3d text on a bright-acid tint —
   invisible on a light toolbar. The dark chip stands out and gives
   the light theme a distinct accent using the BCH secondary from
   whybitcoincash.com's palette.
2026-09-08 01:06:40 +02:00
Local Dev
f8c58538d0 fix: use BCH-primary #0AC18E in light mode + strip Electron token from UA
Two related visibility fixes:

1) Light-mode --acid → #0AC18E (Bitcoin Cash brand primary, from
   whybitcoincash.com's palette per user). Direct swap from #088A66
   (darkened variant) to the on-brand primary. Applied across chrome /
   settings / error / home / approval / messages / bchwallet /
   siawallet / screenshot editor. Dark mode's #d6ff3d is unchanged.

2) User-Agent no longer includes 'theseus-navigator/<ver>' or
   'Electron/<ver>' tokens. Cloudflare's WAF was returning HTTP 503
   'Service Unavailable' to any request carrying those (verified
   directly against whybitcoincash.com — same URL, same headers, only
   the UA differed; plain Chrome UA got 200, Theseus UA got 503).
   Strip both tokens via a stockChromeUA() helper called from
   applyAcceptLanguage(), which whenReady already invokes at boot.
   Standard practice: Brave, Vivaldi, Slack all do the same.

Verified via CDP: navigator.userAgent now reports
  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
  (KHTML, like Gecko) Chrome/130.0.6723.191 Safari/537.36
— indistinguishable from stock Chrome.
2026-09-08 01:04:27 +02:00
Local Dev
9d81c29656 fix(theseus/light): light-mode acid → BCH-teal #088A66 (brand-family, AA on white)
Prior light-mode --acid was #3a5c00 (dark olive-green) — legible but
off-brand. The Bitcoin Cash brand primary is #0AC18E (a teal-leaning
green already used in bchwallet's --bch variable). Darken it a step to
#088A66 for AA text contrast on white (~5:1) while staying in the BCH
family — the light-mode accent now reads as "Bitcoin Cash green,
darkened for legibility" instead of an arbitrary olive.

Applied across every chrome page + addon panel that carries the light
override (chrome / settings / error / home / approval / messages /
bchwallet / siawallet / screenshot editor). Dark mode's #d6ff3d
untouched.
2026-09-08 00:49:46 +02:00
Local Dev
6922ed72ff feat(theseus/screenshot): 0.2.2 — 3 extra swatches, updateURL points at live theseus.x endpoint
Bundled screenshot addon bump:
- version 0.2.1 → 0.2.2
- palette grows from 5 to 8 colors: adds Orange (#ff9500), Blue
  (#0a84ff), Purple (#bf5af2) alongside acid/red/yellow/white/black —
  common annotation colors that were conspicuously missing
- updateURL swings from the aspirational addons.silentmode.st (which
  never resolved) to the live gateway URL
  https://navigate.st/bns/theseus.x/extensions/screenshot/updates.json,
  where the operator's first signed update entry is now published

The gateway URL is deliberate over the bare `theseus.x/...` form: the
add-on updater runs from Node's main-process https module, which uses
the OS resolver. On installs without Ariadne's Thread the OS can't
resolve theseus.x (BNS-only TLD), so the poll would silently fail;
the navigate.st gateway resolves via standard DNS and forwards to the
same BNS-backed Sia content, so every install reaches the endpoint.

First signed update is live at:
  https://navigate.st/bns/theseus.x/extensions/screenshot/updates.json
  https://navigate.st/bns/theseus.x/extensions/screenshot/screenshot-0.2.2.tar.gz
signed 59a35370fdbc9d1e24834fa26c7765d27e8763fe928bfa23b202ca666a6a6973
by the ops key baked into 0.3.19. End-to-end verified via
scratchpad/decoupling-test/verify-live.mjs against the live endpoint:
fetch, sig-verify, download, sha-verify, extract, stage, promote,
backup — all pass.

Installs polling the previous updateURL (addons.silentmode.st) get
this new URL only after their bundled copy is refreshed to 0.2.2,
which means either a Theseus release with 0.2.2 bundled (0.3.20+) or
a signed update at the old URL that carries the URL change (impossible
because addons.silentmode.st doesn't resolve). Ship a Theseus release
that bundles this 0.2.2 to activate the update path on existing
installs; from then on the endpoint self-perpetuates via the theseus.x
URL.
2026-09-08 00:22:49 +02:00
Local Dev
cffb956a4c feat(theseus/addons): signed add-on update endpoint, à la Firefox XPI
Decouples bundled-add-on updates from Theseus releases. An add-on
whose addon.json declares an updateURL can be republished at any time
without shipping a new Theseus installer; existing installs pick it up
on the next boot's +30 s background check.

Client flow (main-process only, no UI touchpoints in this commit):

    initAddons()
    ├── promoteStagedUpdates()   # promote signed stage if newer
    ├── seedBundledAddons()      # bundle wins over on-disk if newer
    └── AddonHost.discoverAndActivate()
    30 s later:
    └── checkAndStageUpdates()   # fetch, verify, download, stage

Signature: Ed25519 over
"silentmode.addon-update-v1|<id>|<version>|<tarball-sha256>",
verified against a hardcoded set of operator pubkeys living in
addon-update-pubkeys.js. Domain-separated so the operator key can't
be tricked into signing a message with a different purpose. Empty
pubkey array is the shipping default — checkAndStageUpdates() then
short-circuits and no outbound requests are made, which is the safe
posture until the operator ceremonies a key in.

Payload: gzipped tar, extracted with the system tar (present on
Win10 1803+, macOS, Linux). Path traversal defended by tar's default
refusal of `..` entries; the extracted manifest's id + version are
re-checked against the signed values before staging.

Staged updates go to <userData>/addons-updates-staged/<id>-<version>/.
Promotion into <userData>/addons/<id>/ reuses seedBundledAddons's
backup dance: existing folder moves to
<userData>/addons-backups/<id>-<oldver>-<timestamp>/ so any local
edits survive.

New files:
- addon-updater.js — client
- addon-update-pubkeys.js — hardcoded pubkeys (empty; edit + rebuild to rotate)
- scripts/generate-update-keypair.mjs — one-time keygen
- scripts/sign-addon-update.mjs — operator packager+signer
- docs/ADDON-UPDATES.md — operator brief + threat model

Wired into main.js at boot; screenshot add-on's addon.json advertises
the reference updateURL for when the endpoint goes live.
2026-09-07 21:58:30 +02:00
Local Dev
c2be569ac1 fix(theseus/addons): reseed bundled add-ons when their version bumps
seedBundledAddons() only copied a bundled add-on when the target folder
was missing, so an updated bundled add-on never landed on any machine
that had ever run Theseus before — the 0.3.14 shipped screenshot editor
would sit in resources/ and be ignored by every dev machine with an
older screenshot/ folder from a previous test.

Compare the bundled addon.json version to the user's on-disk version.
On mismatch, rename the user copy to
<userData>/addons-backups/<id>-<oldver>-<stamp>/ and cp the fresh
bundle in. Backups live outside addonsDir so AddonHost's folder scan
doesn't pick them up as duplicate add-ons under the same manifest id.

Bump screenshot 0.2.0 -> 0.2.1 so the first build carrying this fix
actually reseeds the shipped-0.3.14 editor on existing dev copies.

Users who genuinely fork a bundled add-on should bump their local
version to something different from the bundled one — that keeps them
pinned. Users who edit files without bumping accept upstream updates,
with the timestamped backup as safety net.
2026-09-07 20:53:21 +02:00
Local Dev
15694195d6 feat(theseus/screenshot): full-tab editor + toolbar-menu + open-tab capabilities
Reworks the screenshot addon into the flow the user asked for: the
dock icon opens a small dropdown menu (Visible viewport / Full page /
Region…) instead of the sidebar picker, and each capture opens a
full browser tab hosting an editor.

Two new addon-host capabilities land alongside:
- toolbar-menu: the addon declares an icon + item list in its manifest;
  the chrome dock renders a button that, on click, opens a small menu
  and dispatches the selection to the addon via addon-menu-select IPC.
- open-tab: api.openTab(path) opens a browser tab whose URL is the
  addon's local file. Origin-gated per addon; the editor uses a
  dedicated addon-tab-preload for its main → renderer bridge.

Editor page (editor.html/js/css):
- Crop, arrow, rectangle, circle, freehand pen, text, blur
- Colour swatches (red / yellow / acid / white / black), 3 stroke widths
- Undo/redo command stack, zoom controls
- Save PNG (goes through the download pipeline, chip picks it up)
- Copy to clipboard via ClipboardItem
2026-09-07 00:56:57 +02:00
Local Dev
c9106d4ede fix(theseus/light): darker acid (#3a5c00) + add missing overrides in addon panels
Previous #4d7300 (0.3.10) was still too light against actual white
backgrounds — several tint fills (rgba(214,255,61,X)) and unpatched
addon panels were making the effective color feel bright green. Two
fixes bundled:

1) Bump --acid in every top-level page's light-media block from
   #4d7300 to #3a5c00 — same hue, ~7:1 contrast on #ffffff (was ~5.5:1).
2) Add the missing light-media --acid override to the addon panels
   that were still resolving to #d6ff3d: bchwallet/panel.html,
   siawallet/panel.html, and screenshot/editor.css (was #b4e024, now
   #3a5c00 to match).

Dark mode unchanged. Tint fills (rgba backgrounds at low alpha) still
stay as-is — at 8–15% opacity the specific hue barely matters and the
darker foreground now dominates.
2026-09-07 00:56:33 +02:00
Local Dev
5642959eca feat(theseus/screenshot): bundled screenshot add-on (visible / full page / region)
New capture-tab capability on the addon-host, and the screenshot add-on
uses it to expose three modes in a sidebar launcher panel:

- Visible viewport: Electron's WebContents.capturePage() on the active tab
- Full scrollable page: temp-resize the tab view to document.scrollHeight,
  capturePage, restore
- Region: preload overlays a translucent selection div, tracks mousedown /
  move / up, sends the rect back; main takes the visible capture and
  crops via nativeImage.crop({x,y,width,height})

Saves land in the user's Downloads folder via session.downloadURL — same
pipeline as any file download, so the download chip picks them up.
Filename: theseus-screenshot-<host>-<ISO date>.png. JPEG option for
smaller files.

A follow-up task (task_b9608dc6) reworks this to open captures in a
full-tab editor with crop / draw / annotate / undo / copy-to-clipboard
instead of the current bare launcher.
2026-09-07 00:18:48 +02:00