@bobfrankston/rmfmail 1.2.302 → 1.2.303

package/.commitmsg

@@ -1,49 +1,47 @@
-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.
+The phone's star filter was never asked for, and the chip announcing it landed in a 28px column
+
+"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.
+
+`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.
+
+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.
+
+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) {
@@ -6936,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);