FIXED: Cursor jumped to the start of the corrected word after accepting a suggestion (Gmail and
other contenteditable sites). Root cause in __applyCorrectionImpl() (content.js):
element.replaceWith(textNode) swaps the highlighted span for plain text with no save/restore of
selection at all, so if the caret was anchored inside that span, removing the node collapsed the
browser's selection to the start of the replacement. Fix: before the replacement, check via
Range.comparePoint whether the caret was actually inside the word being corrected, and only then
explicitly collapse the selection to the end of the new text node afterward, so typing continues
right after the correction. If the caret was elsewhere or there was an active text selection,
nothing is touched. Scoped entirely to the plain-contenteditable correction path;
applyCorrectionOverlay() (TEXTAREA overlay), which already manages its own selection, is
untouched. Backup: backups/content.js.bak.20261020-094504


CHANGED: Gmail re-check now scoped to the current sentence, not a fixed 400-char window.
__getActiveEditableScope() in content.js already scoped checks to the block (paragraph/div/li)
containing the caret, but within that block it always sent a fixed +-200-char window around the
caret regardless of sentence boundaries, so editing one sentence resent its already-checked
neighbours on every keystroke. Now it scans outward from the caret for the nearest . ! ? ; (Latin)
or Greek question mark (U+037E) or line break and sends only that sentence; if no boundary is
found in the original 400-char window it falls back to the exact same +-200-char slice as before,
so worst case is unchanged. scopeNode (what gets cleared/redrawn) and non-Gmail sites are
untouched. The 2.5s debounce floor and the chargeLedger per-distinct-error charging are both
unchanged. Backup: backups/content.js.pre-sentence-scope-20261019.bak.

Found reviewing 2.5.1 rather than reported — both defeat the pin that release
added, in the direct-DOM path (Gmail, Google Messages, TinyMCE) where hover
opens the tooltip.
- A hide scheduled before the click survived it. showTooltip() never
cleared tooltipTimeout. Only the mouseover handler cancels a pending
hide, and a click is not guaranteed to be preceded by one — crossing a child
boundary inside the flagged word fires mouseout on its own — so a timer
armed moments earlier fired ~500 ms into the tooltip the user had just
clicked open and closed it. showTooltip() now clears the timer on every
open, which also covers the hover path and the overlay.
- Re-hovering the pinned word silently dropped its pin. The pin was
re-asserted from opts alone on every open, so the mouseover that fires
when the pointer travels off the tooltip back onto its own anchor word
re-entered showTooltip() with no options and reset it to unpinned; the
tooltip then closed on the next drift, exactly as if it had never been
clicked. The pin now also survives when the element being shown is the one
already pinned (element === currentTooltip, read before that field is
reassigned at the end of the function). Hovering a different word still
unpins, so the pin cannot get stuck.
- Verified by lifting the two decision lines straight out of content.js and
driving them through the handler sequences: 6 checks pass, and the same 6
run against the pre-fix file fail 3 — the two above plus its follow-on.

CHANGED - OPTIONS PAGE TAGLINE
- options.html's tagline under the logo/title (.tagline, previously "AI
spellcheck for the web") now reads "AI Spell Checker & Corrector",
matching v2.3.13's renamed extension name.


CHANGED - EXTENSION NAME
- manifest.json's "name" field: "TypoGuard - AI Spell Check & Correction" ->
"TypoGuard - AI Spell Checker & Corrector". This is the name shown in
chrome://extensions, the Chrome Web Store listing, and Firefox's
about:addons -- action.default_title (the toolbar hover tooltip,
"TypoGuard - AI Spell Checker") is a separate string and was left as is.


REVERTED - V2.3.10'S BLUR/REFOCUS SPELLCHECK CACHE-BUST -- DEGRADED TYPOGUARD'S OWN CHECKING ON OUTLOOK WEB
- User accepted native + TypoGuard double-underlining as a reasonable
trade-off on Outlook Web rather than continuing to chase full native
spellcheck suppression, but reported that TypoGuard's own (Gemini-based)
checking had gotten noticeably worse in the same session: the console
showed a flood of "Text changed since request, re-triggering check"
cycles firing mid-typing, well beyond what normal debounced typing
produces.
- Root cause: __forceSpellcheckRefresh() (added in v2.3.10 to fight a
Chromium caching quirk) calls el.blur(); el.focus(); on the field
whenever __applySpellcheckOverride first touches it. That synthetic focus
event re-enters this same file's own focus listener, which calls
__setCheckedText(target, null) and __scheduleCheck(target) -- exactly as
if the user had just tabbed into the field -- discarding whatever text
was already checked and forcing an immediate re-check. On Outlook Web,
where v2.3.11 additionally started overriding document.activeElement
itself, this fired on every such element the override newly reached,
compounding into the flood observed.
- Removed the blur()/focus() body from __applySpellcheckOverride (and the
now-unused __forceSpellcheckRefresh function/its selection-preserving
logic) entirely. Left everything else from v2.3.9-v2.3.11 in place --
setting the spellcheck attribute itself, __watchSpellcheckAttribute's
defensive re-assertion, and __maybeOverrideActiveElementSpellcheck's extra
attribute-only override of document.activeElement -- since none of that
touches focus or fires events.


BUG FIX - V2.3.10'S BLUR/REFOCUS REFRESH NEVER ACTUALLY RAN ON OUTLOOK WEB -- WRONG ELEMENT CHECKED FOR FOCUS
- User re-tested v2.3.10 live: identical result, native "Ορθογραφία" spelling
context menu with real suggestions still appeared on right-clic