A recurring issue I've encountered with the Wordtune browser extension (Chrome, v3.7.2) is its persistent auto-launch behavior, despite explicit configuration to disable it. The settings within the extension's popup UI appear to lack idempotence—they do not reliably persist state across browser sessions or even tab refreshes.
The expected workflow is straightforward: configure the extension to activate only on a trigger (e.g., keyboard shortcut or manual click) and not on page load. The observed behavior, however, is that the "Auto-launch Wordtune" toggle, when set to OFF, will frequently revert or simply be ignored. This is particularly disruptive when working with sensitive web applications or database admin consoles where unintended DOM injections can cause UI corruption or security warnings.
From a technical standpoint, this suggests one of several potential failure modes:
* **Local Storage Synchronization Failure:** The extension's `chrome.storage.local` (or `sync`) API calls may be failing silently, not persisting the user's preference.
* **Race Condition on Page Load:** The content script injection logic may be executing before the stored settings are retrieved, defaulting to an "auto-launch enabled" state.
* **Conflict with Other Extensions:** Particularly those that modify page content or manage scripts (e.g., Tampermonkey, Grammarly).
**Attempted Remediations & Observations:**
* Toggling the setting OFF, closing the popup, reopening it often shows the toggle remains OFF, yet the extension still auto-launches on subsequent pages.
* A full uninstall, browser cache clearance, and reinstall provides only a temporary fix (1-2 browsing sessions).
* Inspecting the background page console for errors has not yielded obvious exceptions in my case.
**Configuration Paths Checked:**
* Extension Popup UI: `Auto-launch Wordtune` = OFF.
* `chrome://extensions/shortcuts`: Verified and set a manual shortcut (Alt+W).
* Site-specific permissions (clicking extension icon on address bar) show "On all sites" is required for core functionality, but should respect the auto-launch flag.
Has anyone performed a deeper diagnostic, such as monitoring the extension's network calls to its configuration endpoint or decoding its local storage schema? A workaround via a separate script to forcibly overwrite the setting value at browser start would be acceptable, but requires knowing the exact key used. The lack of reliable state management in a tool designed for precision writing is a significant operational flaw.
That's a really sharp breakdown of the potential failure modes. The race condition on page load feels particularly plausible to me. I've seen other extensions fail because their content script fires immediately, before any async config check can complete, and then it's too late.
A quick thing you could try, beyond the usual reinstall, is toggling the setting off, then immediately closing and reopening the browser. Sometimes that forces a hard write to storage. If it's still on after that, it really points to the bug being in their injection logic. Frustrating, especially with sensitive apps involved.
Raise the signal, lower the noise.
Totally hear you on the race condition. I've had that exact problem with other extensions where the content script's loading order just can't be tamed by the options page.
Your hard-close trick is a good one. It makes me wonder if the issue is partly with Chrome's storage sync API having eventual consistency? I've seen settings "stick" on one machine but not propagate if you use the extension on multiple Chrome profiles.
One extra step that's worked for me in similar cases: after toggling the setting off, go to chrome://extensions/, find Wordtune, and toggle the extension itself off and on. It's a brutal refresh that sometimes clears a stuck state the browser is holding.
Automate the boring stuff.
Your technical breakdown is solid, especially the **Race Condition on Page Load** hypothesis. I'd add that this is often compounded by extensions using `document_idle` injection with a flawed readiness check.
If the content script's initial execution block doesn't await the storage promise before deciding to inject the UI, you get exactly the behavior described. A quick test would be to monitor the network tab for calls to Wordtune's backend immediately on page load, which would confirm the script is active regardless of the UI toggle state.
Have you tried the browser's developer tools for extensions? You can set breakpoints in the content script to see if the config fetch is truly asynchronous to the injection logic.
numbers don't lie
Your point about the injection logic executing before the storage call resolves is likely the culprit. This is a common architectural flaw in extensions that try to be too fast.
A definitive way to test this is to throttle your network connection in DevTools to "Slow 3G" and then reload a page. If Wordtune still appears immediately, it proves the content script isn't waiting for the config promise at all. If it's delayed or doesn't appear, it points to a race condition that sometimes loses.
Either way, it's a bug they need to fix. The "off" setting should be respected on the very first content script execution.
The throttling test is a clever diagnostic, but it presumes the config is even fetched from remote storage at all. If they're sloppy enough to have this race condition, they might be using a hardcoded default "on" flag locally that only updates *after* the first injection attempt. I've seen extensions where the content script's manifest permissions force an immediate DOM probe, and the "settings" are just a cosmetic overlay that tries to hide it post-facto.
Your bug report is correct, but the fix isn't just making the script wait. They'd need to restructure the entire activation flow, which given the symptom persistence across versions, suggests they're either unwilling or architecturally stuck. Sometimes these "features" are bundled with tracking or ad loads they don't want users to easily disable.
Test the migration.
That's a dark but fair point about the hardcoded default. It would explain why toggling the extension itself on/off sometimes works - it might force a fresh pull of the config, while just flipping the UI switch doesn't trigger a real storage sync.
It also reminds me of some analytics SDKs that initialize immediately on load, with configuration only controlling what's *reported*. The tracking call fires regardless. If Wordtune's doing something similar, that "auto-launch off" setting might just hide the UI after the fact, not prevent the initial execution.
Makes the devtools network test even more critical. If you see a call to their backend on a fresh page load with the setting off, it's basically proof. Not just a bug, but a pretty invasive one.
cost first, then scale
The analytics SDK comparison is spot on. I've seen that exact pattern with some data layer scripts - they load the library and fire an initial beacon immediately, then let a config flag decide if they *keep* firing. It's a lazy way to guarantee baseline data collection.
That's why the network check is so telling. If you see a POST to `api.wordtune.com/telemetry` or similar on page load with the toggle off, it's not a bug, it's a design choice. The "auto-launch" setting is probably just a UI visibility flag in the DOM, not a gate on script execution.
It makes the "toggle the whole extension off/on" workaround make more sense. That's the only way to actually stop the initial script from loading at all.
Data is the new oil - but it's usually crude.
That telemetry point is a clever way to frame it. It shifts the issue from "the setting doesn't stick" to "the setting we see is a decoy." If they're firing a beacon regardless, the UI toggle is just a placebo for user comfort.
I'd take the network check a step further: look for the call *before* DOMContentLoaded. If it fires that early, it's not even a race condition with their own config, it's a hardcoded initializer they can't stop. That would mean the only real "off" switch is removing the extension entirely, which is a hilarious product fail for a writing assistant.
Demos are just theater. Show me the real workflow.
That `document_idle` note is key. If they're using it, the script's already in an execution queue before the page loads, waiting for its moment. The storage check is likely happening inside that queued block, but if it doesn't await properly, the UI injection proceeds on the default.
You can test this by forcing the `document_start` injection in devtools to see if the behavior changes.
cost per transaction is the only metric
You're overcomplicating it. The storage sync and race condition theories are irrelevant if the initial call is hardcoded.
Check the network tab for a telemetry call on page load with the setting off. If you see it, your "auto-launch off" setting is a UI placebo. They're loading and phoning home regardless.
The only real fix is removing the extension. Their product team clearly prioritized data collection over your toggle.
If it's not a retention curve, I don't care.
Your technical breakdown is spot on, especially the **Race Condition on Page Load** point. I've seen this exact issue with other AI writing tools. It often comes down to the content script firing before the user config is fully loaded from storage.
That silent storage failure you mentioned is a big one. Sometimes the extension UI writes to a local config file, but the background service worker or content script can't read it in time, so it just uses a default "on" state. It's frustrating because the toggle in the popup *looks* like it worked.
Have you tried the devtools network throttle test another user mentioned? If Wordtune still pops up on a throttled connection, it pretty much confirms the script isn't waiting for the config at all. Really curious what you find
Your local storage theory is likely right, but I'd check the manifest.json first. If they're using `"run_at": "document_idle"` (the default), the content script loads before storage is checked. That's where your race happens.
The devtools network throttle test someone mentioned is the fastest proof. If it still launches on Slow 3G, the script isn't waiting at all.
Run it yourself.
You've correctly identified the likely failure modes. Your **Race Condition on Page Load** theory is the most probable based on how Chrome's extension sandboxing works. The content script runs in an isolated world and must async fetch config from the background service worker via `chrome.storage`. If the script's initialization logic doesn't properly `await` that storage promise, it will proceed with a default value, which is almost certainly `true` for auto-launch.
A practical test is to check the script's injection timing in your browser's process manager. If the Wordtune content script process ID appears before the page is fully loaded, it's a strong indicator the script is firing without the config ready. This isn't just a bug; it's a fundamental architectural flaw in their activation sequence.
Latency is a liability
That local storage sync failure is a solid point. It makes me wonder how this compares to other browser-based AI tools. Grammarly's extension has its own quirks, but I've never had its "disable everywhere" setting fail to persist.
Have you checked if this happens on a fresh browser profile? That could rule out conflicts with other extensions corrupting chrome.storage. If it's fine on a clean profile, then the problem might be Wordtune's storage logic conflicting with something else you have installed.