@bobfrankston/rmfmail 1.2.301 → 1.2.303

package/.commitmsg

@@ -1,29 +1,47 @@
-Placing the caret in the body is the same act as taking focus
+The phone's star filter was never asked for, and the chip announcing it landed in a 28px column
 
-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).
+"it then says no flagged messages. but there are message flagged" (Bob
+2026-09-04, on Android, with the screenshot). There are 260 — 257 in bobma's
+INBOX alone, and the desktop's own SQL finds every one of them.
 
-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.
+`WebMailxService.getUnifiedInbox` took two parameters. api-client has always
+called it with four: `(page, pageSize, flaggedOnly, dateBasis)`. `getMessages`
+took seven and is called with nine, `flaggedOnly` at position 8. The extras
+fell off the end and JavaScript said nothing — and neither did TypeScript,
+because an implementation with FEWER parameters satisfies an interface
+declaring more. Both dropped arguments are on `MessageQuery`, documented, and
+honoured by the desktop store.
 
-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.
+What was left on the phone was the client's `.flagged-only` CSS rule, which
+hides unflagged rows in the loaded page. That is precisely the arrangement the
+desktop comment has warned about since 2026-06-05: a paginated list whose
+newest 50 messages happen to carry no star shows nothing at all, and every
+starred message deeper in the mailbox is unreachable. The overlay then counted
+the rows it was hiding and reported the truth from where it stood — "A 'flagged
+only' filter is hiding 50 messages" — while the filter that could have found
+the other 260 had never run.
 
-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.
+Both parameters are now threaded through, and the `\Flagged` predicate lives in
+one named constant matching desktop's character for character: two backslashes
+in the SQL literal, because `flags_json` is JSON and the flag is stored
+escaped. `dateBasis` was dropped by the same omission on the same line, so the
+phone has been ordering by arrival time while the desktop ordered by the Date:
+header; it now honours what it is handed. That is a visible change to list
+order on the phone, and it is the order the client has been asking for all
+along — say so if you want it left as it was.
+
+Three tests assert the threading, which is where the bug was. They use a spy
+db, since the failure was an argument that never arrived, not SQL that got it
+wrong.
+
+**The chip, separately.** `#ml-filter-chip` said `display: block; width: 100%`
+and never said `grid-column: 1 / -1`. `.message-list` is a five-column grid,
+every other full-width child declares the span, and this one auto-placed into
+column 1 — the 28px avatar track — so "Showing flagged (★) messages only —
+click to show everything" came out one word per line down the left edge of the
+header. `width: 100%` cannot help there; inside a grid it means 100% of a 28px
+track.
+
+Not changed: the ★ button sits in the search row, next to Server and
+Trash/Spam, which is why reaching for search found a list filter. That is a
+placement judgement, not a bug, so it is yours to call.

package/client/android-bootstrap.bundle.js

@@ -5855,6 +5855,7 @@ var sql_wasm_default = __toBinary("AGFzbQEAAAABnwRFYAJ/fwF/YAF/AX9gA39/fwBgA39/f
 
 // packages/mailx-store-web/db.js
 init_mailx_types();
+var FLAGGED_SQL = " AND flags_json LIKE '%\\\\Flagged%'";
 var JUNK_LOCAL_RE = new RegExp(CONTACT_RULES.junk.localExact, "i");
 var JUNK_LOCAL_SUFFIX_RE = new RegExp(CONTACT_RULES.junk.localSuffix, "i");
 var JUNK_LOCAL_PREFIX_RE = new RegExp(CONTACT_RULES.junk.localPrefix, "i");
@@ -6304,7 +6305,8 @@ var WebMailxDB = class {
     const page = query.page || 1;
     const pageSize = query.pageSize || 50;
     const offset = (page - 1) * pageSize;
-    const sortCol = query.sort === "from" ? "from_name" : query.sort === "subject" ? "subject" : "date";
+    const dateCol = query.dateBasis === "received" ? "date" : "COALESCE(sent_date, date)";
+    const sortCol = query.sort === "from" ? "from_name" : query.sort === "subject" ? "subject" : dateCol;
     const sortDir = query.sortDir || "desc";
     let where = "account_id = ? AND folder_id = ?";
     const params = [query.accountId, query.folderId];
@@ -6313,21 +6315,25 @@ var WebMailxDB = class {
       const term = `%${query.search}%`;
       params.push(term, term, term);
     }
+    if (query.flaggedOnly)
+      where += FLAGGED_SQL;
     const countRow = this.get(`SELECT COUNT(*) as cnt FROM messages WHERE ${where}`, params);
     const total = countRow?.cnt || 0;
     const rows = this.all(`SELECT * FROM messages WHERE ${where} ORDER BY ${sortCol} ${sortDir} LIMIT ? OFFSET ?`, [...params, pageSize, offset]);
     return { items: rows.map((r) => this.rowToEnvelope(r)), total, page, pageSize };
   }
-  getUnifiedInbox(page = 1, pageSize = 50) {
+  getUnifiedInbox(page = 1, pageSize = 50, flaggedOnly = false, dateBasis = "sent") {
     const offset = (page - 1) * pageSize;
     const inboxRows = this.all("SELECT id FROM folders WHERE special_use = 'inbox'");
     if (inboxRows.length === 0)
       return { items: [], total: 0, page, pageSize };
     const ids = inboxRows.map((r) => r.id);
     const placeholders = ids.map(() => "?").join(",");
-    const countRow = this.get(`SELECT COUNT(*) as cnt FROM messages WHERE folder_id IN (${placeholders})`, ids);
+    const flagFilter = flaggedOnly ? FLAGGED_SQL : "";
+    const dateCol = dateBasis === "received" ? "date" : "COALESCE(sent_date, date)";
+    const countRow = this.get(`SELECT COUNT(*) as cnt FROM messages WHERE folder_id IN (${placeholders})${flagFilter}`, ids);
     const total = countRow?.cnt || 0;
-    const rows = this.all(`SELECT * FROM messages WHERE folder_id IN (${placeholders}) ORDER BY date DESC LIMIT ? OFFSET ?`, [...ids, pageSize, offset]);
+    const rows = this.all(`SELECT * FROM messages WHERE folder_id IN (${placeholders})${flagFilter} ORDER BY ${dateCol} DESC LIMIT ? OFFSET ?`, [...ids, pageSize, offset]);
     return { items: rows.map((r) => this.rowToEnvelope(r)), total, page, pageSize };
   }
   getMessageByUid(accountId, uid, folderId) {
@@ -6841,13 +6847,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 +6865,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 +6897,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);
@@ -6923,11 +6942,21 @@ var WebMailxService = class _WebMailxService {
     return this.db.getFolders(accountId);
   }
   // ── Messages ──
-  getUnifiedInbox(page = 1, pageSize = 50) {
-    return this.db.getUnifiedInbox(page, pageSize);
-  }
-  getMessages(accountId, folderId, page = 1, pageSize = 50, sort = "date", sortDir = "desc", search) {
-    return this.db.getMessages({ accountId, folderId, page, pageSize, sort, sortDir, search });
+  // 2026-09-04 — Claude Code (Opus 5), at Bob's direction ("it then says no
+  // flagged messages. but there are message flagged" — 260 of them). Both of
+  // these took two or seven parameters while api-client has always CALLED
+  // them with four and nine: `flaggedOnly` and `dateBasis` fell off the end
+  // and JavaScript said nothing. The star filter therefore existed on the
+  // phone only as the client's `.flagged-only` CSS rule, which can hide
+  // unflagged rows in the loaded page but cannot reach a starred message on
+  // page 4 — so a list whose newest 50 carry no star reads as "no flagged
+  // messages". Keep these signatures in step with api-client's calls; the
+  // language will not do it for you.
+  getUnifiedInbox(page = 1, pageSize = 50, flaggedOnly = false, dateBasis = "sent") {
+    return this.db.getUnifiedInbox(page, pageSize, flaggedOnly, dateBasis);
+  }
+  getMessages(accountId, folderId, page = 1, pageSize = 50, sort = "date", sortDir = "desc", search, flaggedOnly = false, dateBasis = "sent") {
+    return this.db.getMessages({ accountId, folderId, page, pageSize, sort, sortDir, search, flaggedOnly, dateBasis });
   }
   async getMessage(accountId, uid, allowRemote = false, folderId) {
     const envelope = this.db.getMessageByUid(accountId, uid, folderId);
@@ -7486,11 +7515,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");
   }