From 09f45fc200e265701f9f04eadbb66cb4cf146120 Mon Sep 17 00:00:00 2001
From: PMullz <paul@pmds.info>
Date: Sun, 20 Sep 2026 11:37:39 -0400
Subject: [PATCH 1/5] fix(widget): escape a block opener dressed up as an email
 autolink

The exception that spares a line-leading autolink from the HTML-block
escape accepted any local part before the "@". So `<!--a@b>`, `<?a@b>`
and `<![CDATA[a@b>` passed as addresses and were left unescaped, and each
opens a CommonMark block that runs across blank lines until a terminator
that never comes. In a rendered transcript, every later message vanished.

The address form must now start with a letter or digit. Real autolinks
such as <help@example.com> and <https://example.com> are still left
alone. Checked against micromark: after each of those lines the next
message now survives rendering.

Shipped in 1.17.0. Only reachable by a deliberately crafted message, and
only against the author's own export, in an opt-in feature.

Follow-up to #55. The design doc now records the exception, which it
never did.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 .../2026-09-19-conversation-export-design.md    |  9 +++++++++
 .../utils/__tests__/exportConversation.test.ts  | 17 +++++++++++++++++
 widget/src/utils/exportConversation.ts          |  7 +++++--
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/docs/plans/2026-09-19-conversation-export-design.md b/docs/plans/2026-09-19-conversation-export-design.md
index f471e01..adb9951 100644
--- a/docs/plans/2026-09-19-conversation-export-design.md
+++ b/docs/plans/2026-09-19-conversation-export-design.md
@@ -259,6 +259,15 @@ rendered file match what the visitor saw.
    comments entirely. The widget shows such text literally, so the escaped
    form is also the more faithful one. Inline HTML later in a line is left
    alone: it cannot extend past its own paragraph.
+
+   One exception: a line-leading autolink, `<https://example.com>` or
+   `<help@example.com>`, is left alone. It can never open an HTML block, and
+   escaping it shows the brackets and links the wrong destination. The
+   address form must start with a letter or digit. `!`, `?`, and `[` begin
+   exactly the blocks that span blank lines, so `<!--a@b>` is an unterminated
+   comment wearing an address, not an autolink, and is escaped. The first
+   version of this exception accepted any local part, shipped in 1.17.0, and
+   let such a line hide the rest of a rendered transcript.
 4. **Line endings are normalized** to `\n`, and trailing blank lines dropped,
    unless the text ends inside an open code block. There the trailing lines
    are code, so they are left alone and only the block is closed.
diff --git a/widget/src/utils/__tests__/exportConversation.test.ts b/widget/src/utils/__tests__/exportConversation.test.ts
index 27a63f5..cfd9e47 100644
--- a/widget/src/utils/__tests__/exportConversation.test.ts
+++ b/widget/src/utils/__tests__/exportConversation.test.ts
@@ -154,6 +154,23 @@ describe("protectMessageText", () => {
       expect(protectMessageText("<help@example.com>")).toBe(
         "<help@example.com>",
       );
+      expect(protectMessageText("<a.b-c+d@example.co.uk>")).toBe(
+        "<a.b-c+d@example.co.uk>",
+      );
+    });
+
+    it("still escapes a block opener dressed up as an email autolink", () => {
+      // Each of these opens an HTML block that runs across blank lines until a
+      // terminator that never comes, so it would hide every later message.
+      expect(protectMessageText("<!--a@b>")).toBe("\\<!--a@b>");
+      expect(protectMessageText("<!--noreply@example.com>")).toBe(
+        "\\<!--noreply@example.com>",
+      );
+      expect(protectMessageText("<?a@b>")).toBe("\\<?a@b>");
+      expect(protectMessageText("<![CDATA[a@b>")).toBe("\\<![CDATA[a@b>");
+      expect(protectMessageText("<!--https://user@host/x>")).toBe(
+        "\\<!--https://user@host/x>",
+      );
     });
   });
 
diff --git a/widget/src/utils/exportConversation.ts b/widget/src/utils/exportConversation.ts
index 460fac5..bfae77c 100644
--- a/widget/src/utils/exportConversation.ts
+++ b/widget/src/utils/exportConversation.ts
@@ -41,9 +41,12 @@ interface OpenFence {
 const FENCE_OPEN = /^([ \t]*)(`{3,}|~{3,})(.*)$/;
 // A line-leading "<" that CommonMark could read as the start of an HTML block.
 // An autolink (<scheme:host/path> or <user@host>) never opens one, and
-// escaping it would show the brackets and link the wrong destination.
+// escaping it would show the brackets and link the wrong destination. The
+// address must start with a letter or digit: "!", "?" and "[" begin exactly
+// the blocks that run across blank lines, so `<!--a@b>` is an unterminated
+// comment wearing an address, not an autolink.
 const HTML_BLOCK_START =
-  /^( {0,3})<(?![A-Za-z][A-Za-z0-9+.-]{1,31}:[^<>\s]*>|[^\s<>@]+@[^\s<>]+>)(?=[A-Za-z!?/])/;
+  /^( {0,3})<(?![A-Za-z][A-Za-z0-9+.-]{1,31}:[^<>\s]*>|[A-Za-z0-9][^\s<>@]*@[^\s<>]+>)(?=[A-Za-z!?/])/;
 const INDENTED = /^(?: {4}|\t)/;
 
 /** Leading whitespace as columns, with tabs at four-column stops. */

From 03a76a105ff2d22b28e87f0ddefe64ab0839f54a Mon Sep 17 00:00:00 2001
From: PMullz <paul@pmds.info>
Date: Sun, 20 Sep 2026 11:37:44 -0400
Subject: [PATCH 2/5] fix(widget): keep the clipboard fallback from throwing
 while it tidies up

legacyCopy removed its textarea and restored focus in a `finally`, but
neither call was guarded. A throw there replaced the function's result,
and copyText calls it outside its own try, so the promise rejected on
the host page: the one thing copyText promises never to do.

Each cleanup step now has its own guard. A copy that worked still
reports true if tidying up fails, and a failed removal no longer costs
the visitor their focus as well.

Shipped in 1.17.0. Needs a document where remove() or focus() throws, so
it is theoretical, but the contract is "never rejects".

Follow-up to #55.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 widget/src/utils/__tests__/saveText.test.ts | 27 +++++++++++++++++++++
 widget/src/utils/saveText.ts                | 16 +++++++++---
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/widget/src/utils/__tests__/saveText.test.ts b/widget/src/utils/__tests__/saveText.test.ts
index 3e07be2..ea826f9 100644
--- a/widget/src/utils/__tests__/saveText.test.ts
+++ b/widget/src/utils/__tests__/saveText.test.ts
@@ -92,6 +92,33 @@ describe("copyText", () => {
     expect(document.activeElement).toBe(button);
   });
 
+  it("still resolves when returning focus after the fallback throws", async () => {
+    const button = document.createElement("button");
+    document.body.appendChild(button);
+    button.focus();
+    vi.spyOn(button, "focus").mockImplementation(() => {
+      throw new Error("blocked");
+    });
+    (document as Doc).execCommand = vi.fn(() => true);
+
+    // The copy itself worked, so tidying up must not turn it into a failure.
+    await expect(copyText("hello")).resolves.toBe(true);
+    expect(document.querySelector("textarea")).toBeNull();
+  });
+
+  it("returns focus even when removing the textarea throws", async () => {
+    const button = document.createElement("button");
+    document.body.appendChild(button);
+    button.focus();
+    vi.spyOn(HTMLTextAreaElement.prototype, "remove").mockImplementation(() => {
+      throw new Error("blocked");
+    });
+    (document as Doc).execCommand = vi.fn(() => true);
+
+    await expect(copyText("hello")).resolves.toBe(true);
+    expect(document.activeElement).toBe(button);
+  });
+
   it("returns focus to where it was after the fallback", async () => {
     const button = document.createElement("button");
     document.body.appendChild(button);
diff --git a/widget/src/utils/saveText.ts b/widget/src/utils/saveText.ts
index 0d176e6..76900ce 100644
--- a/widget/src/utils/saveText.ts
+++ b/widget/src/utils/saveText.ts
@@ -26,9 +26,19 @@ function legacyCopy(text: string): boolean {
     return false;
   } finally {
     // In a finally, so a refusal cannot leave the textarea on the page or
-    // the visitor's focus inside it.
-    area?.remove();
-    previous?.focus();
+    // the visitor's focus inside it. Each step is guarded on its own: a throw
+    // here would replace the result above and reject the caller's promise,
+    // and a failed removal must not cost the visitor their focus as well.
+    try {
+      area?.remove();
+    } catch {
+      // Nothing more can be done about the textarea.
+    }
+    try {
+      previous?.focus();
+    } catch {
+      // Nor about focus.
+    }
   }
 }
 

From 7a3bf81be589403df824855dc5f71159a7cc2300 Mon Sep 17 00:00:00 2001
From: PMullz <paul@pmds.info>
Date: Sun, 20 Sep 2026 11:53:55 -0400
Subject: [PATCH 3/5] fix(widget): keep copyText from rejecting whatever the
 fallback does

Review of the previous commit found one statement in legacyCopy still
outside every guard: reading document.activeElement runs before its try,
and copyText called legacyCopy outside its own. A throw there rejected
the promise. It cannot realistically happen, but "never rejects" should
be structural, not the result of auditing each statement, so the call
is now wrapped and answers false.

The temporary textarea also leaves the tab order. If removing it ever
fails, it must not stay behind as a keyboard stop that holds the whole
transcript while hidden from assistive technology.

Follow-up to #55.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 widget/src/utils/__tests__/saveText.test.ts | 25 +++++++++++++++++++++
 widget/src/utils/saveText.ts                | 11 ++++++++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/widget/src/utils/__tests__/saveText.test.ts b/widget/src/utils/__tests__/saveText.test.ts
index ea826f9..2f84dde 100644
--- a/widget/src/utils/__tests__/saveText.test.ts
+++ b/widget/src/utils/__tests__/saveText.test.ts
@@ -106,6 +106,31 @@ describe("copyText", () => {
     expect(document.querySelector("textarea")).toBeNull();
   });
 
+  it("resolves false when even reading the focused element throws", async () => {
+    // Nothing in the fallback may reach the caller as a rejection, including
+    // the statements that run before its own try block.
+    vi.spyOn(document, "activeElement", "get").mockImplementation(() => {
+      throw new Error("blocked");
+    });
+    (document as Doc).execCommand = vi.fn(() => true);
+
+    await expect(copyText("hello")).resolves.toBe(false);
+  });
+
+  it("keeps the temporary textarea out of the tab order", async () => {
+    // If it can ever be left behind, it must not become a keyboard stop that
+    // holds the whole transcript while hidden from assistive technology.
+    let tabIndex: number | undefined;
+    (document as Doc).execCommand = vi.fn(() => {
+      tabIndex = document.querySelector("textarea")?.tabIndex;
+      return true;
+    });
+
+    await copyText("hello");
+
+    expect(tabIndex).toBe(-1);
+  });
+
   it("returns focus even when removing the textarea throws", async () => {
     const button = document.createElement("button");
     document.body.appendChild(button);
diff --git a/widget/src/utils/saveText.ts b/widget/src/utils/saveText.ts
index 76900ce..80474f2 100644
--- a/widget/src/utils/saveText.ts
+++ b/widget/src/utils/saveText.ts
@@ -12,6 +12,9 @@ function legacyCopy(text: string): boolean {
     area.value = text;
     area.setAttribute("readonly", "");
     area.setAttribute("aria-hidden", "true");
+    // Out of the tab order: if removal ever fails, it must not be left behind
+    // as a keyboard stop holding the transcript, hidden from assistive tech.
+    area.tabIndex = -1;
     area.style.position = "fixed";
     area.style.top = "0";
     area.style.left = "0";
@@ -61,7 +64,13 @@ export async function copyText(text: string): Promise<boolean> {
   } catch {
     // Refused. Try the legacy path.
   }
-  return legacyCopy(text);
+  try {
+    return legacyCopy(text);
+  } catch {
+    // legacyCopy guards its own steps, but "never rejects" should not depend
+    // on auditing each statement in it, including the ones before its try.
+    return false;
+  }
 }
 
 // Revoking straight away cancels the download in some browsers. FileSaver.js

From d552d516ebc071a46c8da3d2a90ffd48d8f4c214 Mon Sep 17 00:00:00 2001
From: PMullz <paul@pmds.info>
Date: Sun, 20 Sep 2026 11:53:59 -0400
Subject: [PATCH 4/5] test(widget): cover addresses that are autolinks and
 block openers at once

CommonMark allows "?" and "!" in an address, so <?q@example.com> and
<!weird@example.com> are valid autolinks that also open a processing
instruction and a declaration that never close. They are the strongest
cases for the rule that an address must start with a letter or digit.
Confirmed to fail against the 1.17.0 regex.

Follow-up to #55.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 widget/src/utils/__tests__/exportConversation.test.ts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/widget/src/utils/__tests__/exportConversation.test.ts b/widget/src/utils/__tests__/exportConversation.test.ts
index cfd9e47..1da2986 100644
--- a/widget/src/utils/__tests__/exportConversation.test.ts
+++ b/widget/src/utils/__tests__/exportConversation.test.ts
@@ -172,6 +172,16 @@ describe("protectMessageText", () => {
         "\\<!--https://user@host/x>",
       );
     });
+
+    it("escapes an address that is a valid autolink and a block opener at once", () => {
+      // CommonMark allows "?" and "!" in an address, so these really are
+      // autolinks. They also open a processing instruction and a declaration
+      // that never close, and hiding the transcript is the worse outcome.
+      expect(protectMessageText("<?q@example.com>")).toBe("\\<?q@example.com>");
+      expect(protectMessageText("<!weird@example.com>")).toBe(
+        "\\<!weird@example.com>",
+      );
+    });
   });
 
   it("trims trailing whitespace without backtracking over it", () => {

From e639d3baf229f3cee97e00b1759f863631290881 Mon Sep 17 00:00:00 2001
From: PMullz <paul@pmds.info>
Date: Sun, 20 Sep 2026 11:54:04 -0400
Subject: [PATCH 5/5] docs(widget): say why the autolink exception cannot let a
 block through

The comment added with the fix gave a wrong reason. It said "!", "?" and
"[" begin exactly the blocks that span blank lines. "[" begins nothing
(CDATA starts with "!"), and "exactly" is false: script, pre, style and
textarea blocks also span blank lines and start with a letter, which the
address form allows. They stay escaped for a structural reason instead:
the tag name must be followed by whitespace, ">" or the end of the line,
and neither ":" nor "@" is any of those.

A wrong rationale above a regex that has already shipped one bug is how
the next one gets in, so the comment and the design doc now record the
real invariant and what would break it. No behaviour change.

Follow-up to #55.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 .../2026-09-19-conversation-export-design.md  | 22 ++++++++++++++-----
 widget/src/utils/exportConversation.ts        | 14 ++++++++----
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/docs/plans/2026-09-19-conversation-export-design.md b/docs/plans/2026-09-19-conversation-export-design.md
index adb9951..5536ee8 100644
--- a/docs/plans/2026-09-19-conversation-export-design.md
+++ b/docs/plans/2026-09-19-conversation-export-design.md
@@ -262,12 +262,22 @@ rendered file match what the visitor saw.
 
    One exception: a line-leading autolink, `<https://example.com>` or
    `<help@example.com>`, is left alone. It can never open an HTML block, and
-   escaping it shows the brackets and links the wrong destination. The
-   address form must start with a letter or digit. `!`, `?`, and `[` begin
-   exactly the blocks that span blank lines, so `<!--a@b>` is an unterminated
-   comment wearing an address, not an autolink, and is escaped. The first
-   version of this exception accepted any local part, shipped in 1.17.0, and
-   let such a line hide the rest of a rendered transcript.
+   escaping it shows the brackets and links the wrong destination.
+
+   Neither form can let a block through, for two different reasons. The
+   address form must start with a letter or digit, because `!` and `?` begin
+   the comment, processing instruction, declaration, and CDATA blocks:
+   `<!--a@b>` is an unterminated comment wearing an address, not an autolink.
+   That holds even where CommonMark would accept the address, as it does for
+   `<?q@example.com>`: hiding the transcript is the worse outcome. A
+   `<script`, `<pre`, `<style`, or `<textarea` block does start with a
+   letter, but its tag name must be followed by whitespace, `>`, or the end
+   of the line, and neither `:` nor `@` is any of those, so neither form can
+   match one. Loosening either form, by allowing whitespace in the address
+   or dropping the closing `>`, would break that. The first version of this
+   exception accepted any local part, shipped in 1.17.0, and let such a line
+   hide the rest of a rendered transcript.
+
 4. **Line endings are normalized** to `\n`, and trailing blank lines dropped,
    unless the text ends inside an open code block. There the trailing lines
    are code, so they are left alone and only the block is closed.
diff --git a/widget/src/utils/exportConversation.ts b/widget/src/utils/exportConversation.ts
index bfae77c..a39f1ec 100644
--- a/widget/src/utils/exportConversation.ts
+++ b/widget/src/utils/exportConversation.ts
@@ -41,10 +41,16 @@ interface OpenFence {
 const FENCE_OPEN = /^([ \t]*)(`{3,}|~{3,})(.*)$/;
 // A line-leading "<" that CommonMark could read as the start of an HTML block.
 // An autolink (<scheme:host/path> or <user@host>) never opens one, and
-// escaping it would show the brackets and link the wrong destination. The
-// address must start with a letter or digit: "!", "?" and "[" begin exactly
-// the blocks that run across blank lines, so `<!--a@b>` is an unterminated
-// comment wearing an address, not an autolink.
+// escaping it would show the brackets and link the wrong destination.
+//
+// Why neither exception can let a block through. The address must start with
+// a letter or digit, because "!" and "?" begin the comment, processing
+// instruction, declaration and CDATA blocks: `<!--a@b>` is an unterminated
+// comment wearing an address, not an autolink. A `<script`, `<pre`, `<style`
+// or `<textarea` block does start with a letter, but its tag name must be
+// followed by whitespace, ">", or the end of the line, and neither ":" nor
+// "@" is any of those, so neither alternative can match one. Loosening either
+// alternative (whitespace in the address, no closing ">") would break that.
 const HTML_BLOCK_START =
   /^( {0,3})<(?![A-Za-z][A-Za-z0-9+.-]{1,31}:[^<>\s]*>|[A-Za-z0-9][^\s<>@]*@[^\s<>]+>)(?=[A-Za-z!?/])/;
 const INDENTED = /^(?: {4}|\t)/;