@bobfrankston/rmfmail 1.2.301 → 1.2.302

package/.commitmsg

@@ -1,29 +1,49 @@
-Placing the caret in the body is the same act as taking focus
-
-Ctrl+N opens compose with the cursor in the message body instead of the To
-field (Bob 2026-09-03: "^n (and forward?) still start me in the body rather
-than the to field" — and yes, forward too).
-
-applyInit made the decision twice. First it seeded the body and called
-`editor.setCursor(0)`; twenty lines later it picked the first empty field and
-focused it. Reading top to bottom the second one wins, and it does not:
-`setCursor` is not a caret-placement call, it is a focus call. rmf-tiny's
-implementation ends with `editor.focus()` and then re-runs the whole placement
-inside `requestAnimationFrame` — deliberately, to survive the nested-iframe
-focus race that produced the old "have to click in and try again" symptom — so
-it lands after anything applyInit does synchronously afterwards. Quill's
-`setSelection` focuses as well. Whatever order the two lines were written in,
-the editor was always going to win.
-
-So the two are now one decision, made once and up front: `focusTarget` is the
-first field the user still has to fill, To → Subject → body, and `setCursor` is
-asked for only when the answer is the body. On a reply that is still the body —
-To and Subject are filled, and the call also scrolls the quote out of view so
-the empty line is what's on screen, which is the behaviour it exists for. On a
-forward and on new mail it is the To field, untouched.
-
-Forward has been doing this since it grew a quoted body. Ctrl+N joined it in
-v1.2.298, three hours ago: before the account signature reached compose,
-`bodyToRender` was empty for new mail and the branch holding `setCursor` never
-ran at all. The first message anyone composed with a signature was also the
-first one that opened with the cursor in the wrong place.
+Opening a PDF on the phone: a stub, and bytes laundered through UTF-8
+
+"I tried opening a pdf attachment on Android and it said 'opening' but nothing
+happened" (Bob 2026-09-04). In the Android log, verbatim:
+
+    Couldn't open "260901-THE-AI-COMPUTE-RACE-…-PRIVATE-DRAFT.pdf":
+    Not implemented on Android: getAttachment
+
+Two independent bugs, and only the first was reachable.
+
+**getAttachment was a `notImpl` stub.** It sat one line above a comment that
+read "Android opens attachments via the native bridge — getAttachment + base64
+hand-off covers it": a correct description of the design, immediately below the
+throw that made the design impossible. The viewer's Android branch does exactly
+what the comment says — fetch the bytes, hand them to
+`_nativeBridge.openAttachment` — so the throw landed in the chip's catch, which
+posts a banner and restores the label after 600ms. From the phone that is
+"Opening…", and then the chip goes back to normal. It is now implemented: read
+the body through the sync manager, parse, index the attachment the same way
+getMessage numbered the chips, return base64 in the shape the desktop jsonrpc
+returns.
+
+**The parser was destroying the bytes anyway.** The attachment branch called
+`decodeBody()` — which decodes the transfer encoding to bytes and then decodes
+THOSE as UTF-8 text — and re-encoded the result with `TextEncoder`. Every byte
+sequence that is not valid UTF-8 became U+FFFD and came back as the three bytes
+EF BF BD. A PDF, an image or a zip would have arrived corrupt and LONGER than
+it started, with `size` wrong to match, the moment the stub was filled in. The
+transfer-encoding step is now `decodeBodyBytes()` and stops at bytes;
+`decodeBody` is that plus the charset step, so the encodings still have one
+implementation. Attachments take the bytes. Text parts are unaffected.
+
+Verified against the actual message: the web parser and mailparser now produce
+byte-identical output for that PDF — 3,307,996 bytes, `%PDF-` to `%%EOF`.
+tests/attachment-bytes.test.ts covers it with a fixture built from bytes no
+UTF-8 decoder can round-trip, asserting the whole buffer rather than a prefix,
+because the broken version also started with "%PDF".
+
+**One more thing that had never run.** `app/openattachment` in MainPage.xaml.cs
+is the only place in the bridge that reads a RETURN VALUE from JS; every other
+path pushes C#→JS. Since the JS threw first, that code has never once executed.
+Android's evaluateJavascript hands back a JSON-encoded value, so the base64
+arrives quoted and with `=` liable to appear as = — undone before decode,
+and a FormatException now logs the length and first characters of what actually
+arrived instead of dying as "invalid base64".
+
+Untested from here: the 3.3 MB hand-off itself. The bytes are correct and the
+call is wired; whether a payload that size survives one EvaluateJavaScriptAsync
+can only be answered on the device. If it does not, the new log line names it.

package/client/android-bootstrap.bundle.js

@@ -6841,13 +6841,13 @@ function parseMimeParts(body, boundary, topHeaders) {
     }
     if (disposition.includes("attachment") || partType.includes("application/") && !partType.includes("text/")) {
       const filenameMatch = disposition.match(/filename="?([^";\r\n]+)"?/i) || partType.match(/name="?([^";\r\n]+)"?/i);
-      const decoded = decodeBody(partBody, partEncoding);
+      const content = decodeBodyBytes(partBody, partEncoding);
       attachments.push({
         filename: filenameMatch?.[1]?.trim() || `attachment-${attachments.length}`,
         contentType: partType.split(";")[0].trim(),
-        size: decoded.length,
+        size: content.length,
         contentId: (partHeaders.get("content-id") || "").replace(/[<>]/g, ""),
-        content: new TextEncoder().encode(decoded)
+        content
       });
     } else if (partType.includes("text/html")) {
       const charsetMatch = partType.match(/charset="?([^";\s]+)"?/i);
@@ -6859,14 +6859,21 @@ function parseMimeParts(body, boundary, topHeaders) {
   }
   return { html, text, headers: topHeaders, attachments };
 }
-function decodeBody(body, encoding, charset = "utf-8") {
+function base64FromBytes(bytes) {
+  const CHUNK = 32768;
+  let binary = "";
+  for (let i = 0; i < bytes.length; i += CHUNK)
+    binary += String.fromCharCode(...bytes.subarray(i, i + CHUNK));
+  return btoa(binary);
+}
+function decodeBodyBytes(body, encoding) {
   let bytes;
   if (encoding === "base64") {
     try {
       const binary = atob(body.replace(/\s/g, ""));
       bytes = Uint8Array.from(binary, (c) => c.charCodeAt(0));
     } catch {
-      return body;
+      bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
     }
   } else if (encoding === "quoted-printable") {
     const cleaned = body.replace(/=\r?\n/g, "");
@@ -6884,8 +6891,14 @@ function decodeBody(body, encoding, charset = "utf-8") {
   } else if (encoding === "7bit" || encoding === "8bit" || encoding === "" || encoding === "binary") {
     bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
   } else {
-    return body;
+    bytes = Uint8Array.from(body, (c) => c.charCodeAt(0) & 255);
   }
+  return bytes;
+}
+function decodeBody(body, encoding, charset = "utf-8") {
+  if (!["base64", "quoted-printable", "7bit", "8bit", "", "binary"].includes(encoding))
+    return body;
+  const bytes = decodeBodyBytes(body, encoding);
   try {
     const normalized = charset.toLowerCase().replace("windows-", "windows-").replace("iso-", "iso-");
     return new TextDecoder(normalized).decode(bytes);
@@ -7486,11 +7499,49 @@ var WebMailxService = class _WebMailxService {
   async getMessageSource(_accountId, _uid, _folderId) {
     return this.notImpl("getMessageSource");
   }
-  async getAttachment(_accountId, _uid, _attachmentId, _folderId) {
-    return this.notImpl("getAttachment");
+  /** The bytes of one attachment, base64 for the wire — the same shape the
+   *  desktop jsonrpc `getAttachment` case returns, because the same viewer
+   *  code consumes both.
+   *
+   *  2026-09-04 — Claude Code (Opus 5), at Bob's direction ("I tried opening
+   *  a pdf attachment on Android and it said 'opening' but nothing
+   *  happened"). This was a `notImpl` stub sitting immediately above a
+   *  comment explaining that Android opens attachments through the native
+   *  bridge "— getAttachment + base64 hand-off covers it". Both statements
+   *  were in the file at once, and the second was describing this method.
+   *  The viewer's Android branch does what that comment says: it calls
+   *  getAttachment for the bytes and hands them to
+   *  `_nativeBridge.openAttachment`. The throw landed in the chip's catch,
+   *  which posts a banner and restores the label — so from the phone it read
+   *  as "Opening…" and then nothing. Log line, verbatim:
+   *  `Couldn't open "…rev159-PRIVATE-DRAFT.pdf": Not implemented on Android:
+   *  getAttachment`.
+   *
+   *  `attachmentId` is the chip's id, which getMessage assigns as the index
+   *  into this same parser's attachment list — so the two must stay the same
+   *  parse. Re-reading the body rather than caching it keeps that true even
+   *  if the message is re-fetched between opening it and tapping the chip. */
+  async getAttachment(accountId, uid, attachmentId, folderId) {
+    const envelope = this.db.getMessageByUid(accountId, uid, folderId);
+    if (!envelope)
+      throw new Error("Message not found");
+    const raw = await this.syncManager.fetchMessageBody(accountId, envelope.folderId, envelope.uid);
+    if (!raw)
+      throw new Error("Message body isn't downloaded yet \u2014 open the message, then try the attachment again.");
+    const parsed = parseEmailSource(new TextDecoder().decode(raw));
+    const att = parsed.attachments?.[attachmentId];
+    if (!att)
+      throw new Error(`Attachment ${attachmentId} not found in this message`);
+    return {
+      content: base64FromBytes(att.content),
+      contentType: att.contentType || "application/octet-stream",
+      filename: (att.filename || "attachment").replace(/"/g, "")
+    };
   }
   // Android opens attachments via the native bridge (_nativeBridge.openAttachment),
-  // not this service path — getAttachment + base64 hand-off covers it.
+  // which the viewer reaches directly with the bytes getAttachment returns
+  // above; there is no service-side "save it and ask the OS to open it" on a
+  // phone.
   async openAttachment(_accountId, _uid, _attachmentId, _folderId) {
     return this.notImpl("openAttachment");
   }