This is our own extension, so it belongs on the channel the operator key
signs — theseus.x/extensions/docx-editor/ — alongside screenshot, aegis and
pdf-editor. The community catalogue is for extensions published by whoever
owns a BNS name, and routing ours through it would have meant asking a name
owner to vouch for code we wrote.
Drops the community packing script: with one channel there is one publish
path, and it is the one already written down in docs/ADDON-UPDATES.md.
Worth stating plainly, because it is currently true and awkward: Settings
can only *install* from the community catalogue. An extension that is
neither bundled nor catalogued has a working update channel and no way for
anyone to get the first copy. Either it goes back into the build or it needs
a first-party entry point.
Three gaps, one theme: the editor could produce a file but not decide where
it went, what format it was in, or look like anything in the dock.
**Save as…** opens a real file dialog, and the extension typed there picks
the format. Save then writes to that file instead of dropping another copy
in Downloads every time. The renderer never names a path: the dialog returns
an opaque token, and the add-on will only write to a path a dialog actually
returned. An extension page is the least trusted thing in the add-on, and
"write these bytes anywhere" is not a capability it needs.
**PDF** goes through Chromium's own print pipeline in a hidden window — the
same engine as Ctrl+P — on the paper size read out of the document's own
sectPr. For that to match what the user was looking at, the page's
typography had to stop living in editor.css, which the export window can't
reach: it moves to lib/doc-css.js and both surfaces read the one string. The
result embeds subsetted fonts, keeps images, and turns hyperlinks into real
PDF link annotations.
**The icon** is ours. Microsoft's Word mark is a trademark and borrowing it
to look official is not something a browser that talks about sovereignty
should do. icon.svg says "text document" in its own words — a turned corner,
a heading rule, body lines, a pilcrow badge in Silent Mode green — and
`npm run icons` derives the PNGs and addon.json's copy from it, so there is
one drawing rather than several that drift.
Also: the scratch folder follows the profile rename to extensions-data/ via
the api.dataDir the host now provides, instead of creating a stale
addons-data/ beside it.
- pdf-editor 0.1.1 → 0.1.2: manifest.icon is a data:image/svg+xml red PDF
document badge (dock renders it as <img>). Same on toolbar-menu.icon.
Item-level icons dropped — those go through the native OS menu that
doesn't render data URIs.
- translate 0.1.0 → 0.1.1: default LibreTranslate mirror was
translate.argosopentech.com, which is now a dead domain — panel just
said "Failed" on every request. Switched default to
translate.disroot.org (currently up), added a datalist of known
mirrors, and a one-shot migration off the dead default so existing
installs recover on next load.
- docx-editor 0.1.0 → 0.1.1: manifest.icon is a data:image/svg+xml blue
DOC document badge, index.js no longer overrides it with 📝, and the
panel header uses the same inline SVG. Same rationale as pdf-editor —
every extension was rendering as either 📄 or 📝, so PDF and Word
were visually identical to the Notepad.
A .docx editor is a megabyte of vendored library. Bundling it would charge
that to everyone who wanted a browser, including the people who will never
open a Word document in it.
So it leaves the build: out of bundled-addons/, out of extraResources, absent
from a fresh profile. It arrives the way anyone else's extension does —
Settings › Extensions › Community, from the catalogue the gateway builds, and
listed on theseus.x/extensions alongside everything else published there.
That also means it is signed by the owner of a BNS name rather than by the
operator key, which is the right trust story for something that isn't part of
the browser.
`npm run pack` produces the tarball the publish page takes; the signature
needs the publisher name's wallet, so it isn't something the repo can do.
The end-to-end test now installs the extension into a throwaway profile the
way the community installer would, and asserts up front that a fresh profile
doesn't already have it — the bundling is what was being removed, so it is
worth a test that would notice it coming back.
