@hominis/fireforge 0.43.1 → 0.44.0

package/dist/src/core/mochitest-server-port.d.ts

@@ -0,0 +1,42 @@
+import { type MarionettePortHolder } from './marionette-port.js';
+/** Default port the mochitest harness binds its httpd to. */
+export declare const DEFAULT_MOCHITEST_SERVER_PORT = 8888;
+/**
+ * True when the holder is recognizably the mochitest harness's own
+ * `server.js`, launched from an objdir.
+ *
+ * Both halves are required. `server.js` alone is one of the most common
+ * filenames in existence — a developer's unrelated Node service must never
+ * be mistaken for harness debris and offered up for termination — so the
+ * command line must ALSO show the xpcshell/objdir provenance that only the
+ * harness's httpd has.
+ */
+export declare function isMochitestServerHolder(holder: MarionettePortHolder): boolean;
+/**
+ * Refuses a mochitest dispatch when the harness's server port is held, and
+ * — only for a recognized stale harness httpd, and only when the operator
+ * opted in — terminates it first.
+ *
+ * An UNRECOGNIZED listener is a refusal too, never a kill. Refusing is the
+ * kinder outcome: mochitest cannot bind the port either way, so the choice
+ * is between a one-line refusal now and a 370 s stall whose signature says
+ * nothing about ports. But FireForge has no business killing a process it
+ * cannot attribute to the harness.
+ *
+ * Best-effort by construction: {@link probeMarionettePort} reports an
+ * unprobeable port as free, so a host without `lsof` runs exactly as before.
+ *
+ * @param port - Port to probe (default {@link DEFAULT_MOCHITEST_SERVER_PORT})
+ * @param options - `killStaleServer` opts into terminating a recognized holder
+ */
+export declare function ensureMochitestServerPortAvailable(port?: number, options?: {
+    killStaleServer?: boolean;
+}): Promise<void>;
+/**
+ * Builds the operator-facing refusal. Exported for direct unit testing.
+ *
+ * @param port - The probed port
+ * @param holder - The listener found on it
+ * @param recognized - Whether it is the harness's own `server.js`
+ */
+export declare function describeMochitestServerRefusal(port: number, holder: MarionettePortHolder, recognized: boolean): string;

package/dist/src/core/mochitest-server-port.js

@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: EUPL-1.2
+/**
+ * Mochitest HTTP server port preflight.
+ *
+ * The mochitest harness serves its test manifest from an xpcshell-hosted
+ * httpd (`server.js`) on `127.0.0.1:8888`. When a previous run is killed
+ * between browser launch and teardown, that server can survive — sometimes
+ * wedged at 100% CPU and unkillable by the harness's own SIGKILL — and it
+ * keeps the port.
+ *
+ * The next run then does something much worse than failing: its fresh
+ * browser connects to the ZOMBIE server, which cannot serve the new
+ * manifest, so the run stalls between browser startup and `TEST_START` and
+ * dies on the 370 s no-output timeout with `Ran 0 checks`. Nothing in that
+ * signature names the port, so the failure survives fresh builds and reads
+ * as a defect in the change under test — one downstream report spent a
+ * multi-hour bisect on it before `lsof -nP -iTCP:8888` gave the answer in
+ * one line.
+ *
+ * `--kill-stale-marionette` never covered this: it clears the browser and
+ * the Marionette control port, and the httpd is neither. This preflight is
+ * the missing half, and it deliberately reuses {@link probeMarionettePort},
+ * which is port-generic, rather than growing a second probe.
+ */
+import { GeneralError } from '../errors/base.js';
+import { exec } from '../utils/process.js';
+import { probeMarionettePort } from './marionette-port.js';
+/** Default port the mochitest harness binds its httpd to. */
+export const DEFAULT_MOCHITEST_SERVER_PORT = 8888;
+/**
+ * True when the holder is recognizably the mochitest harness's own
+ * `server.js`, launched from an objdir.
+ *
+ * Both halves are required. `server.js` alone is one of the most common
+ * filenames in existence — a developer's unrelated Node service must never
+ * be mistaken for harness debris and offered up for termination — so the
+ * command line must ALSO show the xpcshell/objdir provenance that only the
+ * harness's httpd has.
+ */
+export function isMochitestServerHolder(holder) {
+    const line = holder.commandLine;
+    if (!/\bserver\.js\b/.test(line))
+        return false;
+    return /\bxpcshell\b/.test(line) || /\/obj-[^/\s]*\//.test(line) || /\b_tests\b/.test(line);
+}
+/**
+ * Refuses a mochitest dispatch when the harness's server port is held, and
+ * — only for a recognized stale harness httpd, and only when the operator
+ * opted in — terminates it first.
+ *
+ * An UNRECOGNIZED listener is a refusal too, never a kill. Refusing is the
+ * kinder outcome: mochitest cannot bind the port either way, so the choice
+ * is between a one-line refusal now and a 370 s stall whose signature says
+ * nothing about ports. But FireForge has no business killing a process it
+ * cannot attribute to the harness.
+ *
+ * Best-effort by construction: {@link probeMarionettePort} reports an
+ * unprobeable port as free, so a host without `lsof` runs exactly as before.
+ *
+ * @param port - Port to probe (default {@link DEFAULT_MOCHITEST_SERVER_PORT})
+ * @param options - `killStaleServer` opts into terminating a recognized holder
+ */
+export async function ensureMochitestServerPortAvailable(port = DEFAULT_MOCHITEST_SERVER_PORT, options = {}) {
+    const probe = await probeMarionettePort(port);
+    if (!probe.inUse || !probe.holder)
+        return;
+    const holder = probe.holder;
+    const recognized = isMochitestServerHolder(holder);
+    if (recognized && options.killStaleServer === true) {
+        try {
+            if (process.platform === 'win32') {
+                await exec('powershell.exe', [
+                    '-NoProfile',
+                    '-NonInteractive',
+                    '-Command',
+                    `Stop-Process -Id ${holder.pid} -Force`,
+                ]);
+            }
+            else {
+                process.kill(holder.pid, 'SIGTERM');
+            }
+            return;
+        }
+        catch {
+            // Fall through to the refusal: a wedged httpd is exactly the case
+            // that ignores SIGTERM, and reporting it is more useful than
+            // pretending the port is now free.
+        }
+    }
+    throw new GeneralError(describeMochitestServerRefusal(port, holder, recognized));
+}
+/**
+ * Builds the operator-facing refusal. Exported for direct unit testing.
+ *
+ * @param port - The probed port
+ * @param holder - The listener found on it
+ * @param recognized - Whether it is the harness's own `server.js`
+ */
+export function describeMochitestServerRefusal(port, holder, recognized) {
+    const killHint = process.platform === 'win32'
+        ? `Stop-Process -Id ${holder.pid} -Force`
+        : `kill -9 ${holder.pid}`;
+    const evidence = `The mochitest server port ${String(port)} is already held by ${holder.command} ` +
+        `(PID ${String(holder.pid)}).\n` +
+        `  command: ${holder.commandLine}\n` +
+        "  A browser launched now would connect to THAT server, which cannot serve this run's " +
+        'manifest — the run would stall before TEST_START and die on the no-output timeout with ' +
+        '"Ran 0 checks".\n';
+    if (recognized) {
+        return (evidence +
+            "  This is the mochitest harness's own server.js, so it is debris from an interrupted run. " +
+            'Retry with "--kill-stale-marionette" to have FireForge stop it, or stop it yourself with ' +
+            `"${killHint}" (a wedged httpd can ignore SIGTERM).`);
+    }
+    return (evidence +
+        "  This is NOT the mochitest harness's server.js, so FireForge will not offer to kill it. " +
+        `Stop the holder yourself with "${killHint}" if it is yours, or free the port, then retry. ` +
+        `Diagnose with "lsof -nP -iTCP:${String(port)}".`);
+}

package/dist/src/core/module-resolution-preflight.d.ts

@@ -2,24 +2,22 @@
  * Engine-aware resolution preflight for queue-owned system modules.
  *
  * An `.sys.mjs` that a packaged module imports but whose `EXTRA_JS_MODULES`
- * registration never landed kills every xpcshell suite
- * with `xpcshell return code: -11` and ZERO output — no import error, no
- * stack, nothing. The 0.41.0 `unregistered-system-module` check catches
- * this class, but only in one shape: a module NEWLY CREATED by a patch in
- * the projected queue. The class recurred through the other shape — three
- * modules imported from an ALREADY-EXISTING module before their moz.build
- * lines landed — and cost a full rebuild cycle before anyone recognised it.
+ * registration never landed kills every xpcshell suite with `xpcshell return
+ * code: -11` and ZERO output — no import error, no stack, nothing. The
+ * queue-level `unregistered-system-module` check catches one shape of this:
+ * a module NEWLY CREATED by a patch in the projected queue. The other shape
+ * — modules imported from an ALREADY-EXISTING module before their moz.build
+ * lines land — slips past it entirely.
  *
  * This preflight closes that gap by asking the question against the ENGINE
  * rather than against a projected diff: for every `resource:///modules/…`
  * specifier imported by any queue-owned module, does the module it names
  * exist, and is it registered in a moz.build that covers it?
  *
- * Scope is the queue-owned file set on purpose. A specifier that resolves
- * to no owned file is an UPSTREAM Firefox module, which FireForge does not
+ * Scope is the queue-owned file set on purpose. A specifier that resolves to
+ * no owned file is an UPSTREAM Firefox module, which FireForge does not
  * police and cannot cheaply enumerate; policing only what the fork owns is
- * both the actionable set and the one that produced every recorded
- * incident.
+ * both the actionable set and the one that produces real incidents.
  */
 /** Why a queue-owned module import does not resolve to a packaged module. */
 export type UnresolvedModuleReason = 'missing-file' | 'unregistered';

package/dist/src/core/module-resolution-preflight.js

@@ -3,24 +3,22 @@
  * Engine-aware resolution preflight for queue-owned system modules.
  *
  * An `.sys.mjs` that a packaged module imports but whose `EXTRA_JS_MODULES`
- * registration never landed kills every xpcshell suite
- * with `xpcshell return code: -11` and ZERO output — no import error, no
- * stack, nothing. The 0.41.0 `unregistered-system-module` check catches
- * this class, but only in one shape: a module NEWLY CREATED by a patch in
- * the projected queue. The class recurred through the other shape — three
- * modules imported from an ALREADY-EXISTING module before their moz.build
- * lines landed — and cost a full rebuild cycle before anyone recognised it.
+ * registration never landed kills every xpcshell suite with `xpcshell return
+ * code: -11` and ZERO output — no import error, no stack, nothing. The
+ * queue-level `unregistered-system-module` check catches one shape of this:
+ * a module NEWLY CREATED by a patch in the projected queue. The other shape
+ * — modules imported from an ALREADY-EXISTING module before their moz.build
+ * lines land — slips past it entirely.
  *
  * This preflight closes that gap by asking the question against the ENGINE
  * rather than against a projected diff: for every `resource:///modules/…`
  * specifier imported by any queue-owned module, does the module it names
  * exist, and is it registered in a moz.build that covers it?
  *
- * Scope is the queue-owned file set on purpose. A specifier that resolves
- * to no owned file is an UPSTREAM Firefox module, which FireForge does not
+ * Scope is the queue-owned file set on purpose. A specifier that resolves to
+ * no owned file is an UPSTREAM Firefox module, which FireForge does not
  * police and cannot cheaply enumerate; policing only what the fork owns is
- * both the actionable set and the one that produced every recorded
- * incident.
+ * both the actionable set and the one that produces real incidents.
  */
 import { dirname, join } from 'node:path';
 import { toError } from '../utils/errors.js';

package/dist/src/core/moz-manifest-helpers.d.ts

@@ -0,0 +1,79 @@
+import type { MozBuildToken } from './moz-manifest-tokenizers.js';
+/**
+ * Ordering comparator matching mozbuild's `StrictOrderingOnAppendList`
+ * (`mozbuild.util.UnsortedError`): entries are compared **case-insensitively**,
+ * so `HominisAppearanceController` (`appe`) sorts before
+ * `HominisAppMenuIntegration` (`appm`) even though a raw byte comparison
+ * places the uppercase `M` (0x4D) before the lowercase `e` (0x65).
+ *
+ * A naive `a > b` insertion landed the new entry in byte order, which
+ * `mach configure` then rejected with `UnsortedError`, aborting the build.
+ * Ties on the lower-cased key fall back to byte order so the comparison is
+ * total and stable.
+ */
+export declare function mozbuildSortCompare(a: string, b: string): number;
+/**
+ * Find alphabetical position within tokenized moz.build list items.
+ */
+export declare function findAlphabeticalMozBuildPosition(tokens: MozBuildToken[], newKey: string): {
+    insertIndex: number;
+    previousEntry: string | undefined;
+};
+/**
+ * Inserts one entry into a tokenized jar.mn / jar.inc.mn, honouring an
+ * explicit `--after` anchor and falling back to alphabetical placement when
+ * the anchor is not found.
+ *
+ * Shared by the two jar.mn registrars (browser content, shared CSS), which
+ * differ only in the sort pattern, the sort key and the "could not find the
+ * section" message, so the anchor-fallback semantics — silently falling back
+ * rather than refusing, and reporting `afterFallback` so the caller can say
+ * so — are defined once.
+ *
+ * Deliberately jar.mn-specific: the moz.build list form has no `after` anchor
+ * and no section concept, so a single generic helper over both families
+ * would carry parameters that are meaningless on one side. See
+ * {@link insertMozBuildListEntry} for its twin.
+ *
+ * @param content - Full manifest text
+ * @param entry - The already-formatted line to insert
+ * @param options - Sort pattern/key, refusal message, and optional anchor
+ * @returns The rewritten text plus where it landed and how
+ */
+export declare function insertJarMnEntry(content: string, entry: string, options: {
+    sortPattern: RegExp;
+    sortKey: string;
+    missingSectionMessage: string;
+    after?: string | undefined;
+}): {
+    result: string;
+    insertIndex: number;
+    previousEntry: string | undefined;
+    afterFallback: boolean;
+};
+/**
+ * Inserts one entry alphabetically into a moz.build Python list block.
+ *
+ * Shared by the two moz.build registrars (module list, browser test
+ * manifests), which differ only in the list pattern, the sort key and the
+ * refusal message.
+ *
+ * `tokenizeMozBuildList` **mutates `lines` in place** when it normalizes the
+ * single-line `FOO += []` form into the multi-line shape, and that rewrite is
+ * what makes the caller's `splice` land inside the list body. The splice
+ * below therefore has to run against the same array the tokenizer was
+ * handed; a wrapper that tokenized a copy would silently break it.
+ *
+ * @param content - Full moz.build text
+ * @param entry - The already-formatted line to insert
+ * @param options - List pattern, sort key, and refusal message
+ * @returns The rewritten text and the entry it landed after
+ */
+export declare function insertMozBuildListEntry(content: string, entry: string, options: {
+    listPattern: RegExp;
+    sortKey: string;
+    missingListMessage: string;
+}): {
+    result: string;
+    previousEntry: string | undefined;
+};

package/dist/src/core/moz-manifest-helpers.js

@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: EUPL-1.2
+import { GeneralError } from '../errors/base.js';
+import { escapeRegex } from '../utils/regex.js';
+import { tokenizeJarMn, tokenizeMozBuildList } from './moz-manifest-tokenizers.js';
+/**
+ * Ordering comparator matching mozbuild's `StrictOrderingOnAppendList`
+ * (`mozbuild.util.UnsortedError`): entries are compared **case-insensitively**,
+ * so `HominisAppearanceController` (`appe`) sorts before
+ * `HominisAppMenuIntegration` (`appm`) even though a raw byte comparison
+ * places the uppercase `M` (0x4D) before the lowercase `e` (0x65).
+ *
+ * A naive `a > b` insertion landed the new entry in byte order, which
+ * `mach configure` then rejected with `UnsortedError`, aborting the build.
+ * Ties on the lower-cased key fall back to byte order so the comparison is
+ * total and stable.
+ */
+export function mozbuildSortCompare(a, b) {
+    const la = a.toLowerCase();
+    const lb = b.toLowerCase();
+    if (la < lb)
+        return -1;
+    if (la > lb)
+        return 1;
+    if (a < b)
+        return -1;
+    if (a > b)
+        return 1;
+    return 0;
+}
+/**
+ * Find alphabetical position within a tokenized jar.mn section. Private:
+ * {@link insertJarMnEntry} is the only caller and the only entry point
+ * the jar.mn registrars should use.
+ */
+function findAlphabeticalTokenPosition(tokens, sectionTargetPattern, newKey) {
+    // Find entry tokens in the section matching the pattern
+    const sectionEntries = tokens.filter((t) => t.type === 'entry' && t.parsed && sectionTargetPattern.test(t.parsed.target));
+    let insertLineIndex;
+    let previousEntry;
+    if (sectionEntries.length === 0) {
+        // Empty section: find the section header and insert after it
+        const headerToken = tokens.find((t) => t.type === 'header' || (t.type === 'directive' && sectionTargetPattern.test(t.raw)));
+        if (headerToken) {
+            return { insertIndex: headerToken.lineIndex + 1, previousEntry: undefined };
+        }
+        return { insertIndex: -1, previousEntry: undefined };
+    }
+    // Default: after the last section entry
+    insertLineIndex = (sectionEntries[sectionEntries.length - 1]?.lineIndex ?? 0) + 1;
+    for (const entry of sectionEntries) {
+        if (!entry.parsed)
+            continue;
+        const match = sectionTargetPattern.exec(entry.parsed.target);
+        const key = match?.[1] ?? entry.parsed.target;
+        if (mozbuildSortCompare(key, newKey) > 0) {
+            insertLineIndex = entry.lineIndex;
+            break;
+        }
+        insertLineIndex = entry.lineIndex + 1;
+        previousEntry = entry.raw.trim();
+    }
+    return { insertIndex: insertLineIndex, previousEntry };
+}
+/**
+ * Find alphabetical position within tokenized moz.build list items.
+ */
+export function findAlphabeticalMozBuildPosition(tokens, newKey) {
+    const items = tokens.filter((t) => t.type === 'list-item');
+    if (items.length === 0) {
+        // Insert after list-open
+        const openToken = tokens.find((t) => t.type === 'list-open');
+        return { insertIndex: (openToken?.lineIndex ?? 0) + 1, previousEntry: undefined };
+    }
+    let insertLineIndex = (items[items.length - 1]?.lineIndex ?? 0) + 1;
+    let previousEntry;
+    for (const item of items) {
+        const key = item.parsed?.value ?? '';
+        if (mozbuildSortCompare(key, newKey) > 0) {
+            insertLineIndex = item.lineIndex;
+            break;
+        }
+        insertLineIndex = item.lineIndex + 1;
+        previousEntry = item.raw.trim();
+    }
+    return { insertIndex: insertLineIndex, previousEntry };
+}
+/**
+ * Inserts one entry into a tokenized jar.mn / jar.inc.mn, honouring an
+ * explicit `--after` anchor and falling back to alphabetical placement when
+ * the anchor is not found.
+ *
+ * Shared by the two jar.mn registrars (browser content, shared CSS), which
+ * differ only in the sort pattern, the sort key and the "could not find the
+ * section" message, so the anchor-fallback semantics — silently falling back
+ * rather than refusing, and reporting `afterFallback` so the caller can say
+ * so — are defined once.
+ *
+ * Deliberately jar.mn-specific: the moz.build list form has no `after` anchor
+ * and no section concept, so a single generic helper over both families
+ * would carry parameters that are meaningless on one side. See
+ * {@link insertMozBuildListEntry} for its twin.
+ *
+ * @param content - Full manifest text
+ * @param entry - The already-formatted line to insert
+ * @param options - Sort pattern/key, refusal message, and optional anchor
+ * @returns The rewritten text plus where it landed and how
+ */
+export function insertJarMnEntry(content, entry, options) {
+    const lines = content.split('\n');
+    const tokens = tokenizeJarMn(lines);
+    let afterFallback = false;
+    let insertIndex;
+    let previousEntry;
+    const alphabetical = () => findAlphabeticalTokenPosition(tokens, options.sortPattern, options.sortKey);
+    if (options.after) {
+        const afterPattern = new RegExp(`(?:^|/)${escapeRegex(options.after)}(?:\\s|\\)|$)`);
+        const afterToken = tokens.find((t) => afterPattern.test(t.raw));
+        if (afterToken) {
+            insertIndex = afterToken.lineIndex + 1;
+            previousEntry = afterToken.raw.trim();
+        }
+        else {
+            afterFallback = true;
+            ({ insertIndex, previousEntry } = alphabetical());
+        }
+    }
+    else {
+        ({ insertIndex, previousEntry } = alphabetical());
+    }
+    if (insertIndex === -1) {
+        throw new GeneralError(options.missingSectionMessage);
+    }
+    lines.splice(insertIndex, 0, entry);
+    return { result: lines.join('\n'), insertIndex, previousEntry, afterFallback };
+}
+/**
+ * Inserts one entry alphabetically into a moz.build Python list block.
+ *
+ * Shared by the two moz.build registrars (module list, browser test
+ * manifests), which differ only in the list pattern, the sort key and the
+ * refusal message.
+ *
+ * `tokenizeMozBuildList` **mutates `lines` in place** when it normalizes the
+ * single-line `FOO += []` form into the multi-line shape, and that rewrite is
+ * what makes the caller's `splice` land inside the list body. The splice
+ * below therefore has to run against the same array the tokenizer was
+ * handed; a wrapper that tokenized a copy would silently break it.
+ *
+ * @param content - Full moz.build text
+ * @param entry - The already-formatted line to insert
+ * @param options - List pattern, sort key, and refusal message
+ * @returns The rewritten text and the entry it landed after
+ */
+export function insertMozBuildListEntry(content, entry, options) {
+    const lines = content.split('\n');
+    const listResult = tokenizeMozBuildList(lines, options.listPattern);
+    if (!listResult) {
+        throw new GeneralError(options.missingListMessage);
+    }
+    const { insertIndex, previousEntry } = findAlphabeticalMozBuildPosition(listResult.tokens, options.sortKey);
+    lines.splice(insertIndex, 0, entry);
+    return { result: lines.join('\n'), previousEntry };
+}

package/dist/src/core/{manifest-register.d.ts → moz-manifest-register.d.ts}

@@ -7,9 +7,9 @@
 import type { RegisterResult } from './register-result.js';
 export type { RegisterResult } from './register-result.js';
 export { registerBrowserContent } from './register-browser-content.js';
+export { deregisterTestManifest, registerTestManifest } from './register-browser-test.js';
 export { registerFireForgeModule } from './register-module.js';
 export { registerSharedCSS } from './register-shared-css.js';
-export { deregisterTestManifest, registerTestManifest } from './register-test-manifest.js';
 /**
  * Registers a widget file (mjs or css) in toolkit/content/jar.mn.
  *

package/dist/src/core/{manifest-register.js → moz-manifest-register.js}

@@ -8,12 +8,12 @@
 import { join } from 'node:path';
 import { GeneralError } from '../errors/base.js';
 import { pathExists, readText, writeText } from '../utils/fs.js';
-import { findAlphabeticalPosition } from './manifest-helpers.js';
+import { insertJarMnEntry } from './moz-manifest-helpers.js';
 // Re-export from split modules so existing import sites continue working
 export { registerBrowserContent } from './register-browser-content.js';
+export { deregisterTestManifest, registerTestManifest } from './register-browser-test.js';
 export { registerFireForgeModule } from './register-module.js';
 export { registerSharedCSS } from './register-shared-css.js';
-export { deregisterTestManifest, registerTestManifest } from './register-test-manifest.js';
 // ---------------------------------------------------------------------------
 // toolkit/content/jar.mn — widget registration
 // ---------------------------------------------------------------------------
@@ -30,37 +30,22 @@ export async function registerToolkitWidget(engineDir, tagName, fileName, dryRun
         throw new GeneralError(`Manifest not found: ${manifest}`);
     }
     const entry = `   content/global/elements/${fileName}  (widgets/${tagName}/${fileName})`.replace(/\\/g, '/');
-    let content = await readText(manifestPath);
+    const content = await readText(manifestPath);
     // Idempotency check
     if (content.includes(`content/global/elements/${fileName}`)) {
         return { manifest, entry, skipped: true };
     }
-    const lines = content.split('\n');
-    // Find insertion point among existing content/global/elements/ lines
-    const extractKey = (line) => {
-        const match = /^\s+content\/global\/elements\/([^\s]+)/.exec(line);
-        return match?.[1];
-    };
-    let sectionStart = -1;
-    let sectionEnd = lines.length;
-    for (let i = 0; i < lines.length; i++) {
-        const line = lines[i];
-        if (line === undefined)
-            continue;
-        if (/^\s+content\/global\/elements\//.test(line)) {
-            if (sectionStart === -1)
-                sectionStart = i;
-            sectionEnd = i + 1;
-        }
-    }
-    if (sectionStart === -1) {
-        throw new GeneralError('Could not find content/global/elements/ section in toolkit/content/jar.mn');
-    }
-    const { insertIndex, previousEntry } = findAlphabeticalPosition(lines, sectionStart, sectionEnd, fileName, extractKey);
-    lines.splice(insertIndex, 0, entry);
-    content = lines.join('\n');
+    // Tokenized like the other three jar.mn registrars. The hand-rolled
+    // line scan this replaced re-derived the section bounds and the sort
+    // key with its own regexes, so it was the one jar.mn target that did
+    // not inherit fixes made to the shared path.
+    const { result, previousEntry } = insertJarMnEntry(content, entry, {
+        sortPattern: /content\/global\/elements\/([^\s]+)/,
+        sortKey: fileName,
+        missingSectionMessage: 'Could not find content/global/elements/ section in toolkit/content/jar.mn',
+    });
     if (!dryRun) {
-        await writeText(manifestPath, content);
+        await writeText(manifestPath, result);
     }
     return { manifest, entry, previousEntry, skipped: false };
 }

package/dist/src/core/{manifest-rules.d.ts → moz-manifest-rules.d.ts}

@@ -1,4 +1,4 @@
-import type { RegisterResult } from './manifest-register.js';
+import type { RegisterResult } from './moz-manifest-register.js';
 /** Pattern rules mapping file paths to manifest types */
 export interface PatternRule {
     /** Regex to match the file path (relative to engine/) */
@@ -9,6 +9,15 @@ export interface PatternRule {
     register: (engineDir: string, after: string | undefined, dryRun: boolean, ...args: string[]) => Promise<RegisterResult>;
     /** Extract arguments from the regex match */
     extractArgs: (match: RegExpMatchArray) => string[];
+    /**
+     * Whether this rule's manifest supports `--after` placement.
+     *
+     * Four of the six rules ignore the flag entirely: the CLI accepts
+     * `--after`, the adapter takes it as `_after`, and the operator gets a
+     * silently alphabetical insertion with no indication their placement was
+     * dropped. Declaring it lets {@link registerFile} say so.
+     */
+    supportsAfter: boolean;
 }
 /**
  * Returns manifest registration rules for the supported engine file