@bobfrankston/rmfmail 1.2.300 → 1.2.301

package/.commitmsg

@@ -1,41 +1,29 @@
-The chip claimed every rule was a bulk-mail test without looking at them
+Placing the caret in the body is the same act as taking focus
 
-Altis Hotels' welcome mail (Bob 2026-09-03: "marked as spam but is valid",
-`mailxstore/bobma/90/90fd2404….eml`). The banner on it is already right —
-`info`, no headline, "Your mail server scored this as spam, but altishotels.com
-proved it sent this", and the "Stop warning about marketing@altishotels.com"
-button underneath. What was wrong sat one element above: the score chip's
-tooltip read "Scored by bulk-mail or blocklist rules; the sending domain passed
-DMARC, so the sender is proved" — and then listed, on the next line of the same
-tooltip, `3.2 KAM_ACCOUNTPHISH (Spam that tries to get account information)`,
-which is 3.2 of the message's 8.3 and is neither a bulk-mail nor a blocklist
-rule. A reader who reads both lines has been told two different things about
-the same message by the same tooltip, and the app is the one that is wrong.
+Ctrl+N opens compose with the cursor in the message body instead of the To
+field (Bob 2026-09-03: "^n (and forward?) still start me in the body rather
+than the to field" — and yes, forward too).
 
-The claim was never checked. `benign = proved || kind === "bulk"` picked the
-neutral chip — correctly, that part is about the sender — and the tooltip then
-described the RULES from that same flag. `proved` is a fact about the headers
-and says nothing about any rule; `kind` is the WORST class present and says
-nothing about the rest. Neither one can support a sentence beginning "every
-rule that scored".
+applyInit made the decision twice. First it seeded the body and called
+`editor.setCursor(0)`; twenty lines later it picked the first empty field and
+focused it. Reading top to bottom the second one wins, and it does not:
+`setCursor` is not a caret-placement call, it is a focus call. rmf-tiny's
+implementation ends with `editor.focus()` and then re-runs the whole placement
+inside `requestAnimationFrame` — deliberately, to survive the nested-iframe
+focus race that produced the old "have to click in and try again" symptom — so
+it lands after anything applyInit does synchronously afterwards. Quill's
+`setSelection` focuses as well. Whatever order the two lines were written in,
+the editor was always going to win.
 
-`analyzeServerSpam` now computes `bulkOnly` — every rule that scored is `bulk`
-or `neutral` — and `spamScoreOf` carries it to the chip. The bulk-only sentence
-is said only when it is true. Otherwise the tooltip says what IS established
-and nothing more: the proof, by name, plus "not every rule that scored is a
-bulk-mail test — they are listed below", or for an unproved sender "no forgery
-rule scored", which `kind === "bulk"` does establish. The `info` banner for a
-bulk verdict loses its "— nothing that scored tests who sent it" clause on the
-same condition, since it was making the same unchecked claim.
+So the two are now one decision, made once and up front: `focusTarget` is the
+first field the user still has to fill, To → Subject → body, and `setCursor` is
+asked for only when the answer is the body. On a reply that is still the body —
+To and Subject are filled, and the call also scrolls the quote out of view so
+the empty line is what's on screen, which is the behaviour it exists for. On a
+forward and on new mail it is the To field, untouched.
 
-Measured over the 800 newest messages in the store: 138 raise the neutral chip,
-and 132 of those were being told the score was bulk-mail rules only. Most are
-unflagged mail scoring above half the threshold, which carries no
-X-Spam-Report at all — there the individual scores are unknown, which is
-precisely when a claim about all of them cannot be made.
-
-Not changed, on purpose: KAM_ACCOUNTPHISH stays unclassified. Its description
-says it tests what the message asks for, not who sent it, but "other" is the
-honest answer for a rule this file has no basis to classify, and the cautious
-default is what "other" is for. The fix is to stop asserting past it, not to
-guess at it.
+Forward has been doing this since it grew a quoted body. Ctrl+N joined it in
+v1.2.298, three hours ago: before the account signature reached compose,
+`bodyToRender` was empty for new mail and the branch holding `setCursor` never
+ran at all. The first message anyone composed with a signature was also the
+first one that opened with the cursor in the wrong place.

package/client/compose/compose.bundle.js

@@ -6191,9 +6191,10 @@ function applyInit(init) {
       bodyToRender = isReplyForward ? `<br>${sigBlock}<br>${bodyToRender}` : `${bodyToRender}${sigBlock}`;
     }
   }
+  const focusTarget = !toInput.value ? toInput : !subjectInput.value ? subjectInput : null;
   if (bodyToRender) {
     editor.setHtml(bodyToRender);
-    editor.setCursor(0);
+    if (!focusTarget) editor.setCursor(0);
   }
   if (init.draftUid) {
     draftUid = init.draftUid;
@@ -6214,8 +6215,7 @@ function applyInit(init) {
     renderAttachmentChips();
   }
   setComposeTitle(init.subject || "");
-  if (!toInput.value) toInput.focus();
-  else if (!subjectInput.value) subjectInput.focus();
+  if (focusTarget) focusTarget.focus();
   else editor.focus();
   recordContentBaseline();
   if (init.draftUid && init.draftId) {