@bobfrankston/rmfmail 1.2.303 → 1.2.305

package/client/styles/components.css

@@ -34,6 +34,11 @@
 }
 
 .ctx-item:hover { background: var(--color-bg-hover); }
+/* The menu's default action, set by MenuItem.emphasized — "Move here" in the
+   right-drag menu, the named action in confirmAt. The flag has been passed
+   since the right-drag menu was written and had no rule to render it, so
+   nothing ever looked different (2026-09-04). */
+.ctx-emphasized { font-weight: 600; }
 .ctx-disabled { opacity: 0.4; cursor: default; }
 .ctx-disabled:hover { background: transparent; }
 .ctx-sep { height: 1px; background: var(--color-border); margin: var(--gap-xs) 0; }

package/npmchanges.md

@@ -1470,3 +1470,105 @@ 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.
 
+## v1.2.303 — 2026-09-04
+
+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.
+
+## v1.2.304 — 2026-09-04
+
+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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/rmfmail",
-  "version": "1.2.303",
+  "version": "1.2.305",
   "description": "Local-first email client with IMAP sync and standalone native app",
   "type": "module",
   "main": "bin/mailx.js",
@@ -35,9 +35,9 @@
     "@bobfrankston/iflow-direct": "^0.1.68",
     "@bobfrankston/mailx-host": "^0.1.15",
     "@bobfrankston/mailx-imap": "^0.1.173",
-    "@bobfrankston/mailx-store-web": "^0.1.105",
+    "@bobfrankston/mailx-store-web": "^0.1.106",
     "@bobfrankston/mailx-sync": "^0.1.29",
-    "@bobfrankston/miscinfo": "^1.0.20",
+    "@bobfrankston/miscinfo": "^1.0.21",
     "@bobfrankston/msger": "^0.1.429",
     "@bobfrankston/node-tcp-transport": "^0.1.10",
     "@bobfrankston/oauthsupport": "^1.0.35",
@@ -117,9 +117,9 @@
       "@bobfrankston/iflow-direct": "^0.1.68",
       "@bobfrankston/mailx-host": "^0.1.15",
       "@bobfrankston/mailx-imap": "^0.1.173",
-      "@bobfrankston/mailx-store-web": "^0.1.105",
+      "@bobfrankston/mailx-store-web": "^0.1.106",
       "@bobfrankston/mailx-sync": "^0.1.29",
-      "@bobfrankston/miscinfo": "^1.0.20",
+      "@bobfrankston/miscinfo": "^1.0.21",
       "@bobfrankston/msger": "^0.1.429",
       "@bobfrankston/node-tcp-transport": "^0.1.10",
       "@bobfrankston/oauthsupport": "^1.0.35",