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