@bobfrankston/rmfmail 1.2.302 → 1.2.304

package/.commitmsg

@@ -1,49 +1,49 @@
-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.
+Ask at the pointer, not in the host's dialog
+
+"clicking the x is supposed [to] delete the task but seems to do nothing …
+it eventually puts up a message far from where I clicked" (Bob 2026-09-04,
+with both screenshots).
+
+The × handler called the native `confirm()`. In the WebView that is the host's
+own dialog: titled "msger.localhost says", centred in the window rather than
+under the pointer, arriving late enough that the click reads as having done
+nothing — and blocking the WebView event loop the whole time it is up, which is
+the hazard message-viewer.ts already refuses `alert()` for. Compose reached the
+same conclusion in its own window and wrote an in-page modal; the main window
+never got one, so thirteen `confirm()` calls still go to the host.
+
+`confirmAt(x, y, label)` in context-menu.ts asks the question as a two-item
+menu at the pointer. Built on showContextMenu rather than as a new modal, so
+there is one menu, one dismissal path, and one piece of stay-on-screen clamping
+— that clamping in particular was already solved here for narrow Android
+screens, and a second implementation would have had to learn it again.
+
+The label NAMES its target — `Delete "Records. Berkowitz"`, never "OK". By the
+time a confirmation is read the pointer has moved and the row it came from is
+no longer obvious; a named action can be checked, and "OK" cannot. The
+explanation the old dialog text carried ("removes it from Google Tasks — to
+mark done use the checkbox") is now the item's tooltip: worth having, not worth
+a dialog.
+
+Three call sites move: the row ×, the row context menu's Delete, and the batch
+delete behind the Delete key / trash button. The batch one has no click to
+anchor to, so it asks over the first selected row — where the tasks are and
+where the user is looking.
+
+Two supporting changes:
+
+`ContextMenuOptions.onClose` — fires whichever way the menu goes away, so a
+promise-shaped menu can answer "cancelled" instead of hanging forever on a
+dismissal. An item's click calls closeContextMenu() BEFORE item.action(), so
+onClose always runs first; confirmAt defers its cancel by one microtask, and
+since the action is synchronous and completes within the same task, a chosen
+item has always settled the promise by the time that microtask drains.
+
+`.ctx-emphasized` now renders. `MenuItem.emphasized` has been passed since the
+right-drag menu was written ("Move here" as the default action) and no CSS rule
+ever matched it, so it has never once looked different from its neighbours.
+
+The other ten `confirm()` calls — rebuild, factory reset, permanent delete,
+folder move/delete, contact delete, discard draft — are untouched. They are
+the same dialog with the same problems and they should follow, but each is a
+destructive action worth reading before it moves.

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);