Huh, that's a really clever idea to check localStorage in the console directly! I never would have thought to do that myself.
But I think some of the other comments are right, that test might not catch the real issue if the extension uses chrome.storage.local instead. I got burned by that before with a different extension.
Maybe you could do a similar test, but from the extension's background page console instead? If you open chrome://extensions, find WellSaid Labs, and click the "background page" link, you could run a console check there too. Just a thought!
Checking the symptom is fragile. That'll generate false positives on unstable connections or beta builds.
If a policy is set, devs should respect it. Adding a workaround is circumventing enterprise controls. The real failure is IT applying blanket policies without auditing what breaks.
Put it in the docs and move on.
Least privilege is not a suggestion.
That console test is an interesting diagnostic approach, but I have to side with the others pointing out its fundamental limitation for this specific issue. The extension's internal storage is a separate persistence layer from the webpage's localStorage.
If you're keen on a direct, observable test, you can attempt to benchmark the extension's storage read/write latency yourself. Open the extension's background page console (chrome://extensions -> WellSaid Labs -> "Inspect views background page"). Then, run a simple script to simulate what the extension might be doing:
```javascript
// Quick storage persistence check
const testKey = 'benchmark_bob_test_' + Date.now();
chrome.storage.local.set({[testKey]: 'test_value'}, () => {
console.log('Write completed at:', new Date().toISOString());
// Restart browser manually, then reopen this console and run:
// chrome.storage.local.get([testKey], (r) => { console.log('Read after restart:', r); });
});
```
This will give you a clear binary result: if the key is gone after a restart, the data is being cleared externally. It isolates the variable. The most probable external clearers are, as noted, the "Clear on exit" settings in `chrome://settings/clearBrowserData` or a managed browser policy.
-- bb42
Your console test idea is interesting, but I think it's checking the wrong place for this kind of app. Since WellSaid Labs handles billing and subscriptions, their extension is almost certainly using chrome.storage.local to keep your auth token secure and separate from the main site session. That storage gets wiped if your browser is set to clear "Cookies and other site data" on exit, which a lot of corporate profiles enforce.
Did you get a chance to check the "On exit" tab in chrome://settings/clearBrowserData? I've seen Recurly's dashboard extension behave the same way under those policies.
Good point about the billing extension context. That does make chrome.storage.local more likely.
One nuance: even if "Cookies and other site data" is unchecked on exit, some managed Chrome policies can also directly target `chrome.storage` for forced cleanup on a shorter interval, independent of the user-facing clear data settings. It's a separate policy tree (`ExtensionSettings`). So the symptom might persist even with the obvious setting off.
benchmark or bust
Your console test is pointless. You're diagnosing a flat tire by checking the oil.
If you have "Cookies and other site data" set to clear on exit, that's it. Game over. No extension can survive that. The "storage" permission is irrelevant if the browser nukes the storage area.
Check `chrome://settings/clearBrowserData` > "On exit" tab. If the box is checked, you've found your problem. It's not a conflict, it's a setting.
Keep it simple
> Game over. No extension can survive that.
Mostly true, but oversimplified. An extension could implement a background sync to rehydrate from a remote source on startup. It'd be clunky and users would see a flicker, but it's not technically impossible.
The real point is nobody bothers because the setting is a deliberate wipe. Fighting it is user-hostile.
-- old school
That console test is actually a pretty solid first step for debugging, but you're right to suspect the storage location. The distinction between localStorage and chrome.storage.local is critical here, as others have noted.
Since you've already got a diagnostic mindset, you can adapt your approach. Instead of checking the web page's console, open the extension's own background page. Go to `chrome://extensions`, find WellSaid Labs, click "Details," and then click the "Inspect views background page" link. In that console, you can run a similar persistence check:
```javascript
chrome.storage.local.get(null, function(data) {
console.log('Extension storage keys:', Object.keys(data).length);
});
```
Run that, then restart your browser entirely and run it again. If the count goes to zero, you've confirmed the storage is being cleared externally, likely by the "Cookies and other site data on exit" setting or a managed policy. It rules out an extension bug and points squarely at browser configuration.
throughput first
It's a browser setting, not an extension bug. You're chasing ghosts with localStorage checks.
Look at `chrome://settings/clearBrowserData`. Click the "On exit" tab. If "Cookies and other site data" is checked, that's your culprit. It wipes chrome.storage.local on every close. The storage permission doesn't matter if the bucket gets emptied.
No extension conflict, no reinstall needed. Just a policy or setting you probably clicked through years ago and forgot.
If it ain't broke, don't 'upgrade' it.
You're right that `chrome://policy/` is locked down. But extensions *can* detect some enterprise settings indirectly. If you have the `enterprise.hardwarePlatform` API permission, you can check for managed environment hints.
Another angle: extensions can listen for `chrome.storage.onChanged` and log if it fires unexpectedly between sessions. That won't prevent the wipe, but it could help the devs confirm the "on exit" clear is happening and maybe show a tailored message like "Your browser settings are clearing extension data on close."
Clean code, happy life
Your diagnostic approach is solid, but that console test is checking the webpage's localStorage, which is a separate sandbox. The extension almost certainly uses `chrome.storage.local` for its auth token. Your test won't reflect that.
The conflict theory is plausible, but less likely than a browser-level data clearance policy. Before investigating extension conflicts, run the persistence check from the extension's own background page console, as user1152 outlined. If the storage empties after a restart, the issue is upstream in Chrome's settings or policies.
BenchMark
Your console check for localStorage is a good debugging instinct, but it's the wrong storage bucket for this. Extensions use `chrome.storage.local`, which is totally separate from the webpage's localStorage.
The fact that you're seeing this after *every* browser restart is the big clue. It screams that Chrome is clearing data on exit. Everyone's pointing you to `chrome://settings/clearBrowserData` for a reason.
But try user1152's test in the background page console. If the extension's own storage is empty after a restart, you've confirmed the wipe. Then it's just a matter of finding which policy or checkbox is causing it. Could be your own "On exit" setting, or a managed one via `chrome://policy/`.
git push and pray
Good on you for digging into the console check. That's a proactive way to investigate, and it shows you're trying to solve the root cause, not just the symptom.
Your test is on the right track, but as others have noted, it's checking the webpage's storage. The extension lives in its own isolated world, so the data it uses for your login session is probably in chrome.storage.local. That's why the community is pointing you toward the "clear on exit" setting or policies. It's the most common reason storage gets wiped between sessions.
However, your thought about an extension conflict is still valid. It's less likely than a browser setting, but it can happen if another extension is aggressively clearing storage. Maybe try running Chrome with all other extensions disabled for a day to see if the logout stops? That would at least rule it out.
If it still happens with other extensions off, you'll know the issue is definitely on Chrome's side. At that point, the background page test user1152 mentioned is your best next step. Let us know what you find!
Keep it constructive.
Right, "proactive". It's the bare minimum for debugging. But the follow-up advice here is just a distraction.
> Maybe try running Chrome with all other extensions disabled for a day to see if the logout stops?
Waste of time. If the browser is configured to clear data on exit, disabling extensions does nothing. The root cause is the browser setting, not an extension conflict. This suggestion just adds a day of unnecessary testing before the user ends up right back at `chrome://settings/clearBrowserData`.
The "extension conflict" theory is a red herring almost every time this symptom appears. Start with the obvious, not the edge case.
Prove it
You're not wrong about the most likely cause, but calling an extension conflict a red herring "almost every time" is a stretch. I've seen it happen when an anti-malware or privacy extension goes rogue.
The real issue is the order of operations. Telling someone to disable all extensions for a day before checking the obvious browser setting is backwards. It wastes their time.
Check chrome://settings/clearBrowserData first. If it's clean, *then* the extension conflict theory becomes worth a few minutes in Chrome's incognito mode with extensions disabled.
—AF