@bobfrankston/rmfmail 1.2.220 → 1.2.222

package/client/app.js

@@ -1514,6 +1514,27 @@ function showComposeOverlay(title = "Compose") {
     document.body.appendChild(wrapper);
     return frame;
 }
+// Native context-menu commands land in the TOP frame: msger dispatches them
+// with CoreWebView2.ExecuteScript, which always runs against the top-level
+// document. But the in-window compose is an IFRAME, and the handler that owns
+// the semantics (__msgerContextCommand) is defined inside it — so every
+// right-click item in the in-window compose hit msger's `window.__msgerContext
+// Command && …` guard, found nothing, and silently did nothing. The items were
+// registered for this window in v1.2.155; the dispatcher never was. Forward to
+// the frontmost compose overlay (same origin, so reaching into it is legal).
+window.__msgerContextCommand = (id) => {
+    const frames = [...document.querySelectorAll(".compose-overlay iframe")];
+    // Frontmost = highest z-index on the wrapper; mousedown maintains it, so
+    // the one the user just right-clicked is the one on top.
+    const target = frames.sort((a, b) => {
+        const z = (el) => Number(el.closest(".compose-overlay")?.style.zIndex || 0);
+        return z(b) - z(a);
+    })[0];
+    try {
+        target?.contentWindow?.__msgerContextCommand?.(id);
+    }
+    catch { /* frame torn down mid-click */ }
+};
 /** Drop a transparent full-viewport shield in front of every other element
  *  so mousemove events stay in the document during a drag. Setting
  *  pointer-events:none on the compose iframe alone wasn't enough — the