@bobfrankston/rmfmail 1.2.304 → 1.2.305

package/.commitmsg

@@ -1,49 +1,40 @@
-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.
+One click on a task disabled Delete for the whole app
+
+"I press del and the message is not deleted whether I'm in the letter or
+summary and trashcan is not working" (Bob 2026-09-05).
+
+`deleteSelection()` — the one route for the Delete key, Ctrl+D, and both trash
+buttons — gave tasks an unconditional priority: if `getSelectedTaskUuids()` was
+non-empty it deleted tasks and returned, whatever the user was actually looking
+at. A task selection is set by a single click on a task row in the sidebar, is
+never cleared by anything done in the mail panes, and has no indicator outside
+the sidebar. So one stray click on a task turned off Delete and both trash
+buttons for messages, indefinitely, and the only symptom was nothing happening.
+Invisible modal state deciding what a destructive gesture means — the same
+fault as a filter that reads as a selection.
+
+The daemon log shows it exactly: at the moment of the attempt there is a
+getMessage and an updateFlags and no trashMessages at all. Nothing was slow or
+failing; the gesture never left the client.
+
+Routing now follows the pane the user last acted in, tracked on capture-phase
+pointerdown so it lands before any handler that stops propagation and before
+focus moves. The toolbar buttons sit in neither pane, so clicking one leaves
+that reading as the user's last real interaction set it — which is the point,
+since the button is how you act on what you were just doing. Select tasks and
+press Delete and the tasks still go, which is what the priority rule was
+written for; the part that was never intended is gone. A delete routed to
+messages also clears any leftover task selection, so the sidebar stops showing
+rows as chosen after the gesture has moved on.
+
+I made this worse yesterday and should say so. Before v1.2.304 the swallowed
+delete at least put up the native confirm — misplaced and late, but visible, so
+"my delete went to the tasks" was discoverable. Moving that question to a menu
+anchored over the task pane made the misrouting completely silent whenever the
+sidebar was collapsed or scrolled away. The routing bug was already there; my
+change removed the last evidence of it.
+
+Also guarded, from the same cause: the batch confirm measured its anchor with
+getBoundingClientRect on a possibly-hidden sidebar, which is 0x0 at 0,0 — it
+now falls back to the middle of the window rather than asking in a corner
+nobody is looking at.

package/client/app.bundle.js

@@ -6542,6 +6542,7 @@ var init_outbox_view = __esm({
 // client/components/calendar-sidebar.js
 var calendar_sidebar_exports = {};
 __export(calendar_sidebar_exports, {
+  clearTaskSelection: () => clearTaskSelection,
   deleteSelectedTasks: () => deleteSelectedTasks,
   getSelectedTaskUuids: () => getSelectedTaskUuids,
   hideCalendarSidebar: () => hideCalendarSidebar,
@@ -6649,6 +6650,12 @@ async function renderCalendarList() {
   if (lastEvents.length > 0)
     renderEvents(lastEvents);
 }
+function clearTaskSelection() {
+  if (selectedTaskUuids.size === 0)
+    return;
+  selectedTaskUuids.clear();
+  void renderTasks();
+}
 function getSelectedTaskUuids() {
   return [...selectedTaskUuids];
 }
@@ -6657,9 +6664,10 @@ async function deleteSelectedTasks() {
   if (uuids.length === 0)
     return;
   const anchorEl = document.querySelector(".cal-side-task.selected") || document.getElementById("cal-side-tasks");
-  const r = anchorEl?.getBoundingClientRect();
+  const rect = anchorEl?.getBoundingClientRect();
+  const r = rect && rect.width > 0 && rect.height > 0 ? rect : { left: window.innerWidth / 2 - 60, bottom: window.innerHeight / 3 };
   const label = uuids.length === 1 ? `Delete "${document.querySelector(".cal-side-task.selected .cal-side-task-title")?.textContent || "this task"}"` : `Delete ${uuids.length} tasks`;
-  if (!await confirmAt(r ? r.left + 24 : 80, r ? r.bottom : 80, label, { tooltip: TASK_DELETE_NOTE }))
+  if (!await confirmAt(r.left + 24, r.bottom, label, { tooltip: TASK_DELETE_NOTE }))
     return;
   selectedTaskUuids.clear();
   for (const uuid of uuids) {
@@ -10588,13 +10596,21 @@ function popUndo() {
   }
   return null;
 }
+var lastActionPane = "messages";
+document.addEventListener("pointerdown", (e) => {
+  const t = e.target;
+  if (!t?.closest) return;
+  if (t.closest("#cal-side-tasks")) lastActionPane = "tasks";
+  else if (t.closest(".message-list, .message-viewer, #ml-body, #message-viewer")) lastActionPane = "messages";
+}, true);
 async function deleteSelection() {
   try {
     const sidebar = await Promise.resolve().then(() => (init_calendar_sidebar(), calendar_sidebar_exports));
-    if (sidebar.getSelectedTaskUuids().length > 0) {
+    if (lastActionPane === "tasks" && sidebar.getSelectedTaskUuids().length > 0) {
       await sidebar.deleteSelectedTasks();
       return;
     }
+    if (sidebar.getSelectedTaskUuids().length > 0) sidebar.clearTaskSelection();
   } catch {
   }
   await deleteSelectedMessages();