theseus/bundled-addons/screenshot/addon.json

16 lines
718 B
JSON
Raw Normal View History

{
"id": "screenshot",
"name": "Screenshot",
"version": "0.6.6",
"description": "Capture the current tab — visible viewport, full page, or a rectangle you draw. Preview + annotate editor (crop, arrow, line, rect, ellipse, pen, resizable text, blur/mosaic redaction, undo, copy, save) live inside the sidebar. Expand the sidebar to full window for a canvas-sized editor.",
"author": "Silent Mode",
"icon": "📸",
"main": "index.js",
Theseus: start extensions on first use, Startup switches in Settings Every enabled add-on used to be activated synchronously in initAddons(), during app.whenReady and before the window exists. That is the largest launch cost left (boot tracer, 2026-10-03). An add-on can now say "activation": "on-demand" in addon.json. It is then listed at launch but not started. Its declared surfaces stay live: "panels" (new: sidebar panels declared up front), toolbar-menu, context-menu-items and the page-inject bridge, whose source is read on the first matching page. activate() runs on first real use: a panel opened, a menu or context item picked, a message from its panel, tab or page bridge, a Settings addon-invoke, a wiz:// link (for Aegis). All of those go through AddonHost.dispatch(), which starts the add-on and waits for it, so no call is dropped. Concurrent callers share one activation, and activations run one at a time. Startup stays the default: the host cannot tell what an older add-on does in activate(). request-filter add-ons and add-ons that declare no surface are forced to startup. If activate() returns a promise, calls wait for it (at most 5 s). api.startAtLaunch(bool) lets an on-demand add-on ask to be started at launch again (for live relay sessions). Converted: notepad, screenshot, translate, docx-editor, pdf-editor, vpn (none has launch-time work: no file association, no auto-connect, and add-on file tabs are not part of the saved session). Shield and Cookie Pop-ups stay startup: Shield owns the request filter and must see the first request; Cookie Pop-ups costs ~6 ms and acts unasked on every page. Aegis stays startup and untouched: another session owns it. See NOTE-aegis-on-demand.md (next commit). Settings › Performance › Startup: - "Start extensions when first used" (default on). Off = all at launch; switching it off starts the waiting add-ons immediately. - "Start the wallet at launch". Shown disabled with a hint until the installed Aegis manifest allows on-demand. It applies with no Settings change once Aegis opts in. - "Preload common menus" gates prewarmOverlays(). - "Use lightest" preset. New keys are plain SETTINGS_DEFAULTS through the existing settings-set. No new IPC channels. Measured: boot-trace, fresh profile, --seconds 20 so the 30 s add-on OTA poll can't swap Aegis mid-series; warm runs 2-3 of two paired series. - Add-on activation at launch: 121-154 ms -> 104-174 ms. The six converted add-ons went from 16-20 ms to 0. The rest is Shield (83-148 ms, noisy) and Aegis (15 ms in this tree's 0.9.0). - Toolbar painted: 1278-1584 ms -> 1282-1481 ms (within noise). - With "Preload common menus" off: 0 overlays prewarmed, 8 processes instead of 11, about 50-70 MB less at 15 s. The bundled add-on versions are not bumped. Existing profiles keep their old addon.json, and so stay on startup activation, until those add-ons ship with a higher version (seedBundledAddons only reseeds a strictly newer bundle).
2026-10-03 16:05:32 +02:00
"activation": "on-demand",
"panels": [
{ "id": "main", "title": "Screenshot", "icon": "📸", "page": "panel.html" }
],
feat(theseus/screenshot): 0.4.0 — editor lives inside the sidebar, maximizable User report: the sidebar preview lands correctly, but the moment the editor opens in its own tab the picture is blank. Rather than chase that class of handoff race again, put the editor in the same webContents as the panel: the sidebar view navigates panel.html ↔ editor.html in place. Same document object, same silentmode.storage surface, no cross-tab __pending transfer at all. - panel.html "Edit" button now calls silentmode.invoke("arm", …) — the add-on rewrites __pending with the currently-previewed capture's bytes, and the panel does location.href = "editor.html?name=…". Sidebar view loads the editor with the same preload; editor.js's storage-based load path pulls the pending entry out and paints. - editor.html gains a "Back" arrow (returns to panel.html) and a maximize / restore icon. - discard() now navigates to panel.html instead of closeTab() — there is no tab to close. - Manifest drops the "open-tab" capability entirely (no more full-tab editor); keeps sidebar-panel + capture-tab. Framework: new silentmode.sidebar.{maximize, restore, toggleMax, isMax, onMaxChange}. main.js honours them via new sidebar-maximize / -restore / -toggle-max / -is-max IPCs, remembering the pre-maximize width so a restore drops back exactly. The sidebar drag-grip auto-exits maximize mode on any user drag, so pulling the edge always lands on the pre-max value plus/minus the delta. sidebar-preload exposes the surface; chrome.html renderer is untouched — this is a per-panel affordance. Editor tools (crop / arrow / rect / ellipse / pen / text / mosaic / undo / redo / copy / save) unchanged. Save still goes through Chromium's <a download> path, so the file lands in Downloads and appears in the download chip like any other save. Bundled but not shipped — leaving version bump + deploy to parent session.
2026-09-08 22:18:41 +02:00
"capabilities": ["sidebar-panel", "capture-tab"],
feat(theseus/screenshot): 0.3.0 — sidebar-first flow with explicit "open in tab" 0.3.33 still ships blank screenshots because the whole toolbar-menu → auto- open-editor path can't be made race-free: the moment the editor tab opens it becomes the active tab, and a snapshot of the editor's own tab (before its canvas has drawn from storage) is a valid-looking 24 KB all-white PNG. The lastCapturableTabId fallback I added in a279864 catches the second click, but the first click can still land on the addon-owned tab whenever the user re-triggers before setActive has settled. Rebuild the UX so this class of race can't happen at all: - Drop the toolbar-menu capability. Manifest is back to sidebar-panel + capture-tab + open-tab, so the dock icon opens the panel (never the editor directly). No dropdown, no clip-under-tab-view issue, no auto- jump into an addon-owned tab. - Sidebar has the three capture buttons + a preview <img> + a "Open in editor tab" button. The preview is fed a data:image/png URL returned straight from api.captureTab, rendered inside the sidebar's own document — same origin, no file:// cross-directory gotcha, and the user can see immediately whether the shot actually landed. - Editor.html tab opens only on an explicit "Open in editor tab" click. The addon rewrites __pending at that moment (so the editor always sees the just-selected capture even if a prior editor tab drained the entry), then api.openTab("editor.html", {name}). The editor's storage-based load path is unchanged. - Recent captures ring is kept and now exposed as a horizontal thumbnail strip in the sidebar; clicking a tile re-previews that capture and arms "Open in editor tab" for it. Editor page (editor.html/js/css) unchanged — same crop / arrow / rect / ellipse / pen / text / mosaic-redact / undo / redo / copy / save. Bundled but not shipped — leaving version bump + deploy to the parent session.
2026-09-08 20:26:48 +02:00
"updateURL": "https://navigate.st/bns/theseus.x/extensions/screenshot/updates.json"
}