Blogger's Don't track my views setting gets reset after some time - Probable cause; Chrome extn for notification if reset

Last updated on 25 Sep. 2025

Quick Info

Blogger Don't Track My Views Checker: Chrome Extension to check whether Blogger is tracking your own pageviews across multiple blogs - GitHub repo. The README.md explains how to install, configure and use it. 

I have tested the 'release' download (smaller download than repo cloning or download) on an alternate computer (Dell mini Laptop) which does not have the GitHub repo. It worked as expected.

The context for above extension is the problem of some, if not all, of my Blogger blogs reverting to OFF for "Don't track my views for this blog" even though I do not make such a change on any of my devices where I am logged in with the same Google a/c and access my Blogger blogs. The probable cause is deletion of a Blogger cookie named _ns under some circumstances. This cookie seems to be associated with this "Don't track my views for this blog" setting. It is set as a session cookie which may be getting wiped out (removed) when my Chrome browser session is not restored or when I log out of my Google account.

The above extension helps in easily getting notified of Blogger cookie _ns being absent (and so, in all probability, "Don't track my views for this blog" being OFF) for any of my configured Blogger blogs. Then I can take the action of manually checking "Don't track my views for this blog" setting for those blogs and change it back to ON, if required.

12:22 25 September 2025 Update: I have been using this Chrome extension for over a week now and it seems to be working OK. Today, in particular, it showed me that two of my five Blogger blogs had "Don't track" OFF. I manually checked the two blogs settings and it had "Don't track my views ..." unchecked. So I checked them and then when I clicked on the extension icon, it showed me that two other blogs now had "Don't track" OFF! That was very surprising as just a few minutes earlier it had not reported that those two blogs had "Don't track" OFF even though its logic would have checked those blogs' cookies too. I checked the settings for these two (later reported) blogs and they too had "Don't track" OFF which I changed to ON. Now clicking on the extension icon reports "Don't track" ON for all five of my Blogger blogs.

In the past few days, I surely did not log off from my Google account on this Windows login id. As far as I can recall, over these past few days Chrome did not ask me for whether I should restore my Chrome session, and so I presume that Chrome did not create a new session. Then how did these Blogger blog settings change? Note that if it was an extension logic reporting error then when I had checked Blogger blog settings, it would have not been in sync with extension's report. But it was in sync and so the extension was reporting the status accurately.

As of now, I have no idea what triggered this change in "Don't track my views ..." setting (from checked/ON to unchecked/OFF) in four of my five Blogger blogs. This extension's utility value has been reinforced by today's above events.

Details

Given below are edited extracts from my recent chat with ChatGPT (CG), "Blogger own views tracking issue".

Me: About Blogger Stats: Manage tracking your own pageviews:
I am having a problem of some of my Blogger blogs reverting to OFF for "Don't track my views for this blog." even though I do not make such a selection on any of my devices where I am logged in with the same Google a/c and access my Blogger blogs. On my computer devices, I have gone to Blogger in each device and set "Don't track my views for this blog." to ON. However, the problem is still happening at times. 

My suspicion now is that on my mobile device, I sometimes access my Blogger blog through Chrome. Perhaps access from that mobile browser is triggering the problem. R u with me so far?
...

Me: How do I check whether my mobile (Android) Chrome browser has this setting to ON or OFF for my Blogger blogs? Should I try to access Blogger.com on mobile Chrome and then check? ... Note that I have Blogger app installed on my mobile but I don't recall seeing such a setting there.

CG: This setting doesn’t live in the Blogger mobile app at all — you’re right that you won’t find it there. It’s tied to your Blogger account settings per blog, and Blogger enforces it via a cookie in your browser (not a global Google-account flag). ...
[CG suggested logging in to Blogger on Android Chrome.]

Me: Hmm. Signing in on blogger.com on mobile Chrome with its small screen size would be problematic. Isn't there some easier way?

CG: You’re right — Blogger’s full dashboard on a mobile screen is cramped and fiddly. Unfortunately, Blogger hasn’t exposed the “Don’t track my views” toggle in the mobile app or in a lightweight mobile UI.

...
Me: Can u search the net and see if others are facing a similar problem with Blogger and if so, how they are handling it?
...

Me: In my case, it retains the value for some days across browser open/close as well as system restarts. Then it gets automaticatically set back to OFF. Pls. give me articles that match that.

CG: Yes — I found a relevant thread from Google Support that more or less matches your description: people saying their “Don’t track my views” setting in Blogger does stick for a while (across browser restarts etc.), then later reverts to OFF automatically. Google Help

Here are the key parts I found + what people deduced, which seem similar to what you’re seeing:

🌐 What others said

From the Google Support thread “My selection of 'Don't track my views for this blog' keeps resetting”:

  • A user writes that the option resets even though they didn’t explicitly change it. Google Help

  • Someone else (or the official reply) points out that the cookie associated with that setting is a session cookie — meaning it may have no long-term expiry and thus can expire (or be lost) when certain events happen (e.g. logging out, session ending, or possibly after some time). Google Help

  • Also people in that thread say it reverts after some days. Google Help

So this matches your pattern: keeps ON for some days (so the session/cookie is working), then flips back (when session/cookie is no longer valid, or gets cleared).

...

Me: https://support.google.com/blogger/thread/352039900?utm_source=chatgpt.com seems to match my case. I looked up Dev Tools in Chrome and found that I too have an _ns cookie which is set to session. Now as per above article: Session" => "expire at end of the session", so it will be deleted when you log out or when you close the browser (and do not restore the previous session). 
------ 
I usually don't log out of Google but sometimes that happens [Google forces a re-login OR I do log out temporarily for some reason]. So does it mean that every time I log out of Google, the cookie gets cleared? Note that the setting is remebered across system reboots (but without me having logged off from Google).

CG: Yes — you’ve pieced it together exactly right. Let me unpack it clearly:

🔑 About the _ns cookie

  • That _ns cookie you saw in DevTools is indeed the one Blogger uses for the “Don’t track my views” flag.

  • It’s marked as a session cookie, which means:

    • It has no explicit expiry date.

    • Its lifetime is tied to your login session in that browser profile.

✅ Why it survives some reboots

  • If you don’t log out of Google and you restore the browser session (Chrome remembers your tabs and cookies), then the _ns cookie stays alive.

  • That’s why your setting persists across browser restarts and even system reboots — as long as you remain signed in and Chrome keeps your session intact.

❌ Why it resets

  • If you log out of Google in that browser, the session is considered ended → Chrome deletes session cookies tied to that login → _ns cookie vanishes.

  • Next time you log in, Blogger won’t see the _ns cookie, so it defaults back to OFF.

  • That’s exactly the “after some days, it reverts” behavior you’re observing.

⚠️ Implication

Yes — every time you log out of Google on that browser profile, you should expect the “Don’t track my views” setting to reset, because its cookie is wiped along with the logout.

👉 Two ways people handle this, based on what I’ve read:

  1. Avoid logging out of Google on the browsers/devices where you need this setting stable.

  2. If you must log out sometimes → just get into the habit of re-checking Stats → Settings after logging back in, and re-enable “Don’t track my views.”


Me: Hmm. Sometimes I choose not to restore Google Chrome session in cases where it prompts me. Does that mean that it would get reset then? 

Also at times, I close all Chrome tabs having Google account related sites. Will that also result in the cookie getting reset?

CG: Good questions 👌 — let’s separate the two scenarios:

1️⃣ When you don’t restore the Chrome session

  • If Chrome is closed, session cookies (like _ns) normally die unless Chrome restores them.

  • That’s why restoring the session usually preserves the cookie — Chrome treats it as “continuing the same login session.”

  • If you choose not to restore, Chrome starts a fresh session → session cookies are gone → _ns cookie disappears → Blogger resets to OFF.

So yes: if you skip restoring, that can cause the reset.

2️⃣ When you close only Google-related tabs but leave Chrome open

  • Simply closing Gmail/Drive/Blogger tabs doesn’t kill the _ns cookie.

  • As long as Chrome itself is still running and you’re still signed into Google in that browser profile, the cookie stays alive.

  • The reset only happens when:

    • You log out of your Google account in Chrome, or

    • You close Chrome entirely without restoring the session later.

✅ So in practice:

  • Logout or non-restored browser exit → cookie wiped → setting OFF.

  • Closing just Google tabs (while Chrome is still open) → cookie stays.


Me: what if I close Chrome browser and do a PC reboot? Note that in such cases Chrome remembers my Google account login. But will it delete the session cookie?

CG: That’s a subtle but very important case 👍 Let’s unpack it carefully:

🔑 What happens when you close Chrome + reboot PC

  1. Chrome shut down:

    • When you close Chrome, all session cookies are supposed to be discarded.

    • BUT Chrome has an exception: if you have “Continue where you left off” enabled or you manually restore the previous session, Chrome reloads those session cookies.

    • That’s why your _ns cookie sometimes survives across reboots.

  2. PC reboot:

    • A reboot itself doesn’t matter — the key is what Chrome does on restart.

    • If Chrome remembers your session (tabs + cookies), then _ns comes back and Blogger still sees “Don’t track my views = ON.”

    • If Chrome starts fresh (new session), then _ns is gone, Blogger resets to OFF.

  3. Google account login persistence:

    • Chrome remembering you’re signed into Google is a separate thing from Blogger’s _ns cookie.

    • Even if your Google login persists (so Gmail/Drive open without password), the _ns session cookie may still have been discarded — meaning Blogger thinks the tracking preference was never set.

✅ So in short:

  • Close + reboot + restore session → cookie survives → setting stays ON.

  • Close + reboot without restoring → cookie is gone → setting resets to OFF.

  • The Google login persistence doesn’t guarantee Blogger’s “Don’t track” preference survives, because they’re controlled by different cookies.

👉 Do you want me to show you how to check Chrome’s startup setting (“Continue where you left off”) and make sure it’s always restoring sessions, so you reduce the chance of Blogger resetting things?

[I said yes to above ... Settings -> On Startup showed that 'Continue where you left off' is selected.]

Me ... But even with that, in some scenarios (like me having to relogin in Google or me choosing not to restore session when presented with that choice - usually on system hang followed by system forced reset/reboot), I may have been not continuing the previous session, and that's where I may have lost the cookie setting. Am I right?

CG: Yes 👍 you’ve got it exactly right.

Even though “Continue where you left off” is selected:

  • ✅ If Chrome closes/reopens normally → _ns cookie stays → Blogger remembers Don’t track my views.

  • ❌ If you choose not to restore session (like after a crash/system hang reboot) → Chrome discards the old session cookies → _ns cookie is lost → Blogger resets to OFF.

  • ❌ If you re-login to Google (sign out or session expires) → session cookies are cleared → Blogger resets to OFF.

So the behavior you’re seeing — Blogger remembering the setting for days, but then “mysteriously” resetting — is consistent with these scenarios.

👉 In short:
Your suspicion is correct — it’s not random; it happens only when the session continuity is broken (manual no-restore, forced reboot without session restore, or re-login).

Me: How can we confirm that _ns indeed is the related Blogger cookie?

CG: Good question 👌 — confirming that _ns is the cookie tied to “Don’t track my views” needs a bit of detective work, but it’s possible. Here’s how you can check:

🔎 Method 1: Manual testing with DevTools

  1. Open Chrome → Go to Blogger Dashboard.

  2. Open DevTools (F12) → Application tab → Storage → Cookies.

    • Look for the _ns cookie under blogger.com.

    • Note its value (e.g. 1 or 0) while your setting is ON.

  3. Now go to Stats → Manage tracking your own pageviews and toggle the setting to OFF.

  4. Refresh and check the cookie value again.

    • If _ns changes (or disappears), that’s strong evidence it’s the one controlling the setting.

...

Me: Method 1: The value is 2 now with Don't track setting selected. Shall I uncheck it and see if the value changes?

[CG said yes.]

Me: On unselecting it, and refreshing cookies info. in Dev Tools, _ns cookie is not shown (so cookie must be getting deleted). On selecting it, and refreshing cookies info. in Dev Tools, _ns cookie is shown with value as 2 (cookie must be getting created).

CG: Excellent 👏 — that confirms it beyond doubt:

  • ✅ When “Don’t track my views” is ON → Blogger creates _ns cookie with value 2.

  • ❌ When it’s OFF → Blogger deletes _ns cookie.

So _ns is exactly the cookie that stores your “don’t track my pageviews” preference.

🔍 What the behavior means

  • _ns is a session cookie → it’s not persistent.

  • That’s why it survives across browser reopen/reboot only if the session is restored.

  • If session continuity is broken (logout, crash, or you choose not to restore), _ns vanishes → Blogger defaults to tracking your views (OFF).

👉 Now you’ve got proof.

Would you like me to suggest ways to make _ns behave more “persistent” (so you don’t lose the setting as often), like using Chrome cookie overrides or extensions?

Me: https://support.google.com/blogger/thread/352039900?utm_source=chatgpt.com suggests changing session to 2050 using Dev Tools.

...

Me: I am hesitant to do the DevTools fix as it is a hack and not a Google suggested fix. Don't know if that might trip something else up. Instead is there some easy way that I can get notified when I visit Blogger that the setting is OFF?

[CG gave some options including a Chrome extension option.]

Me: My own Chrome extension (with you providing source code) is something I am willing to try so long as that does not create a significant performance issue. The extension can fire only when Chrome process is started (not on new tab).

[CG provided some code. I went through many iterations but did not get a proper solution. There were two problems with CG solutions:
  • Retrieving and testing the cookie was not working properly.
  • The message from the Chrome extension would go to background worker log whereas I wanted an alert.
Eventually I decided to stop doing the vibe-coding effort. Later I felt I should invest a little time in learning about Chrome extension development and see if I can figure out the cause of the above issues in CG provided Chrome extension code. For learning, CG gave some simple extension code but that too tripped up on showing the message part. So I then switched to going through Chrome extension documentation.]

Me: I am going to try this documentation tutorial extn https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world
...
Me: it worked as expected. but it shows a static popup. ...Next step would be to see how it shows a dynamic message generated by the extn. .... I will try that later .... eventually I hope to get back to the code you gave and then examine for myself why your code is not working.

============================

Later I had another chat with CG, 'Chrome extension update' on 15 Sep. 2025. Given below are some edited extracts from it.

[I had gone through a few Chrome extension documentation tutorials.
Then I tried modifying this extension that I was trying to get developed with CG by adding a simple hello-world type popup. The popup worked - associated GitHub repo commit: Added Hello on click.
Next I simply removed the default_popup property from action property in manifest.json. Now it was getting configured Blogger blogs' cookies correctly and writing on service worker console - associated GitHub repo commit: Gets Blogger cookie correctly and writes on service worker console. That was suprising as IFIRC, it was not doing this earlier on (before hello-world popup change). Perhaps I had not observed the situation correctly then.
I updated CG with this status.]

Me: First I would like to understand why the code works for service worker console (it was not working in the past, IFIRC). BTW I also have an icon.png. 
I think the only change I made was to add: 
   "default_icon": "icon.png", 
to action property in manifest.json. 

Also, this gets the cookies correctly (I tested with some variation) irrespective of which tab I am on - This chat tab, or Blogger dashboard tab or Chrome documentation tab. 

Does Chrome allow for any domain's cookie to be accessed via this extension? I had thought that it would allow only accessing cookies for the domain associated with current tab.

CG: ... So the real fix is permissions + proper triggering of the service worker, not the icon itself. The default_icon just ensures the extension has something to show in the toolbar.

[I did not agree with above view of CG. But I let that pass as I felt maybe I had not tested it correctly then.]

2. Why it works regardless of the active tab

That’s expected 👍

The cookies API lets extensions read/write cookies for any site listed in host_permissions, completely independent of which tab is open.

So when you do:

chrome.cookies.get({ url: domain, name: "_ns" })

Chrome checks the cookie jar for that domain, not the tab.

That’s why you can be on this ChatGPT tab, and it still reads Blogger cookies.

3. Does Chrome allow access to any domain’s cookies?

Not quite.

Rules:

  • You need "cookies" permission AND explicit host_permissions for the domains whose cookies you want.

  • Without host_permissions, chrome.cookies.get() for that domain will fail.

  • There is also a privacy safeguard: you cannot read cookies for sites you haven’t declared.

So in your case, you can only read cookies from:

  • ravisiyer.blogspot.com

  • ravisiyermisc.blogspot.com

  • raviswdev.blogspot.com

If you tried google.com or nytimes.com, it wouldn’t work unless you added them to host_permissions.

✅ So in short:

  • Service worker console now works because you gave the extension the right host permissions and the background service worker is actually being triggered.

  • Cookie access is domain-based, not tab-based. As long as you declare the host permissions, you can check those cookies no matter what tab is open.


Me: Oh I see! If I were writing a regular HTML Javascript page code, I was under the impression that the JS cookie API only gave me cookies for the domain on which the HTML page was hosted/setup.

CG: Exactly ✅ You’ve spotted the key difference between regular webpage JS and a Chrome extension:

🟦 Regular HTML + JS (running inside a web page)

  • document.cookie only gives you cookies that belong to the current page’s origin (same domain + path rules).

  • You cannot peek into cookies for google.com while sitting on example.com.

  • That’s the same-origin policy at work → it protects user privacy.

🟦 Chrome Extension (with cookies permission)

  • The extension runs with special privileges.

  • Using chrome.cookies.get(...), it can fetch cookies for any domain explicitly listed in host_permissions in your manifest.json.

  • It doesn’t matter which tab is active or even if no tab of that site is open — it queries Chrome’s internal cookie store directly.

  • So the extension acts like a trusted agent, as long as you’ve declared which domains you need access to.

So the mental model is:

  • Webpage JS → “sandboxed, can only see its own cookies” 🍪

  • Extension JS → “privileged, can ask Chrome for cookies of declared domains” 🔑


Me: Oh I see! I think even Chrome Dev Tools shows cookies only for the origin of page in current tab. Or is there a way in Dev Tools to see cookies of all domains?

CG: You’re right 👍 — Chrome DevTools behaves more like the “webpage JS world” than like an extension.

🔍 What you see in DevTools:

  • Application → Storage → Cookies:

    • Shows cookies only for the origin of the current tab (e.g. if you’re on https://example.com, you’ll see only example.com cookies and its subdomains).

  • Console → document.cookie:

    • Same story — you only get cookies visible to JS for that page’s origin.

  • You don’t get a master list of cookies across all sites in DevTools.

🛠 How to see all cookies in Chrome (outside DevTools):

  • chrome://settings/siteData → Chrome’s internal cookie manager (all sites).

  • chrome://cookies/ (old-style UI, sometimes hidden).

  • Or programmatically via Chrome extension with cookies permission (like you’re doing now).

So:

  • DevTools = origin-scoped (like normal JS sandbox).

  • Chrome itself / extensions = can see global cookie store (if permissions allow).


Me: chrome://settings/siteData just takes me to Settings screen.

[CG made some probably obsolete suggestions (like the above) to see all cookies in Chrome from its UI. None of them worked.] 

Can you find other such pages which give us some kind of confirmation that now through Chrome UI alone, you cannot see all cookies for all domains in one screen.

CG: You're correct in observing that recent versions of Chrome have limited the ability to view cookies across all domains through the browser's user interface. This change has been noted by users and discussed in various forums.

For instance, a user on Super User mentioned: "It was possible to see all cookies content for all domains in the settings with Chrome version 107.0.5304.107. I updated to 108.0.5359.72 and now it's only possible to delete data or set domain rights..." Super User

This indicates that earlier versions allowed users to view detailed cookie information for all domains, but this functionality was removed in subsequent updates.

Additionally, discussions on Reddit highlight similar concerns: "Went to change some Cookie settings on a new install today, and under 'Privacy and Security', where it normally has the sub-setting 'Cookies and other site data', there is now only a sub-setting 'Third-party Cookies'." Reddit

These changes reflect a broader trend towards enhancing user privacy and security, potentially at the cost of transparency regarding cookie data.

...

Me: You said: These changes reflect a broader trend towards enhancing user privacy and security, potentially at the cost of transparency regarding cookie data. 
==== 
Can you give me a reference page from Google Chrome stating the above?

...

Me: You could not get a reference page from Google Chrome documentation, it seems. So your statement is a view based on some other posts and what I have shared. I think u r right but it would have been great if you could have got a Google chrome documentaton page saying that as that would then be completely reliable and definitive.

CG: Exactly — you’ve summarized it perfectly. ✅

  • My earlier statement about the trend toward privacy/security is an interpretation based on user reports, forum discussions, and your observations.

  • I could not find an official Google Chrome documentation page that explicitly says: “We removed the ability to view all cookies across all domains in the UI to improve privacy/security.”

So while the trend is clearly visible in practice, there isn’t a definitive, official statement from Google confirming it.

...

Me: Hmm. I am quite surprised that my extension could get cookies data for all sites which I as a user on Chrome cannot get unless I visit each of those sites. Shows the power of programmatic work done by the extension. 

OK. I think now my key questions about why/how the code works, have been answered. Next I would like to explore a simple popup showing the Blogger cookie presence/absence (in addition to service worker console log). Is that possible?

[CG provided some code.]

Me: Made the changes. Clicking the extn icon shows the popup with correct cookie status messages. Great! But service worker console is empty. ... I had faced a similar issue in a previous trial - looks like if we have a popup.html tied to action of default_popup, then the background worker listening stuff does not fire.

[I think this is the GitHub repo commit at this stage: Shows popup on extension click with Blogger cookie status; Removed hello popup]

CG: Exactly — that behavior is normal in Manifest V3. Let me explain carefully:

Why your service worker console is empty now

  1. In MV3, the background script is a service worker, which is event-driven and non-persistent.

    • It only wakes up when there’s an event to handle (like chrome.runtime.onStartup, chrome.action.onClicked, alarms, messages, etc.).

  2. Previously, when you didn’t have a default_popup, clicking the extension icon fired chrome.action.onClicked, which triggered checkBlogs() in the service worker.

  3. Now with default_popup:

    • Clicking the icon opens the popup instead of firing onClicked.

    • The service worker never wakes up just from the click → console shows nothing.

So this explains the behavior you observed.

...

Me: Popup message is enough for me on extn. click. I don't need service worker console message for that. 

But on startup, can I get a popup message with cookie status (so I don't need to click the extn. icon everytime I start Chrome)?

CG: Ah — now we’re hitting a key Manifest V3 limitation:

1️⃣ Why you cannot show a popup automatically on startup

  • The popup (default_popup) is only shown when the user clicks the extension icon.

  • Chrome does not allow extensions to automatically open popups without user interaction — this is a security/UX restriction.

So there’s no way to pop up popup.html on startup like you can in some regular apps.

2️⃣ What you can do on startup

  • Use the service worker to check cookies automatically on Chrome startup (using chrome.runtime.onStartup).

  • Instead of opening a popup, you can show the status via:

    1. Chrome notifications (chrome.notifications)

    2. Badge text on the extension icon (chrome.action.setBadgeText)

    3. Console log (if you still want developer info)

...

Me: I would like to explore badge text on extn. icon. Can u give me the code changes for that?

[CG provided code. It did not work initially ...]

Me: In the previous code (not your suggested code above), service worker was listening to msg (onMessage): 
chrome.runtime.onMessage.addListener((msg) => { 
 if (msg.action === "updateBadge") updateBadge(); 
}); 
----- 
and popup.js was sending the message: 
// Tell background.js to update the badge 
chrome.runtime.sendMessage({ action: "updateBadge" }); 
----- 
Why did that not work?

CG: Ah — now I can explain exactly why that previous code didn’t work in MV3.

1️⃣ Service worker lifecycle in Manifest V3

  • The background script is a service worker, not persistent.

  • It only exists (“wakes up”) when an event triggers it:

    • chrome.runtime.onStartup

    • chrome.runtime.onInstalled

    • chrome.runtime.onMessage

    • Alarms, web requests, etc.

  • Once all events finish, the service worker goes idle and may be terminated.

2️⃣ Why sending a message from popup.js might fail

  • When you click the extension icon:

    1. Popup opens (popup.html) → popup.js executes.

    2. popup.js immediately calls:

      chrome.runtime.sendMessage({ action: "updateBadge" });

  • At this precise moment, the service worker might not be awake yet.

Subtle MV3 behavior:

  • If the service worker is not already running, Chrome wakes it up for some events, but onMessage listeners are sometimes not immediately registered until the service worker “initializes”.

  • This is why sending the message sometimes had no effect — the worker didn’t catch it in time.

3️⃣ Why my suggested fix works

  • By calling updateBadge() immediately in the service worker global scope, the worker always runs at least once when it starts.

  • The onMessage listener is still there for popup messages, so subsequent updates also work.

  • Also, using a non-empty badge text ensures it appears even if all cookies are ON.

✅ Key MV3 lesson

  1. Service workers are event-driven, ephemeral.

  2. Don’t rely on a message from the popup alone to always update a badge — the worker may not be awake yet.

  3. Always call your initialization logic when the worker starts.

...

Me: I think I am understanding your explanation ... But when you say "the worker may not be awake yet", you mean the worker is simply not there at that point of time. Isn't it? I mean, it is not like the worker sleeping waiting for a message which will wake it up (which is how it would be something like a socket listener thread in a regular C++ socket program).

CG: Exactly — you’ve got it 💡

In Manifest V3:

  • The service worker doesn’t exist at all until Chrome decides it needs it (event-driven).

  • It’s not a persistent process that’s “sleeping” or listening in the background like a thread in a C++ program.

  • When an event happens (e.g., onMessage, onStartup, alarm, web request), Chrome spins up the service worker, runs the event handler, and then may terminate it after it goes idle.

So in your previous code:

  • When popup.js sent a message, if the worker wasn’t already alive, Chrome might wake it up.

  • But if the onMessage listener hadn’t been registered yet at that instant (because the worker is just starting), the message could get lost.

  • Unlike a socket listener, there’s no persistent listening thread waiting for messages. The worker must be running and have the listener registered at the moment the message arrives.

✅ Key distinction:

Regular persistent program (e.g., C++ thread)MV3 service worker
Always alive, can sleep & wake on eventsNot alive until triggered
Socket/message listeners are always readyListeners exist only after worker starts
Can guarantee catching any messageMessage may be lost if worker not yet initialized

So the robust way is:

  1. Initialize immediately in the worker global scope (call updateBadge()).

  2. Keep onMessage listeners for subsequent updates from popup.

This guarantees the badge updates reliably in MV3.

...

Me: The specific case I need to understand is when I start Chrome and after some time click on the extn. icon. So by now there would be enough time for background worker to have spun up. Why doesn't the background worker get the message sent by popup.js on extn. icon click? I think u r saying that Chrome may have terminated the background worker as it was idle and so the message gets lost. am i right?

CG: Exactly — you’ve understood it correctly. ✅

Let me explain step by step for your scenario:

Scenario

  1. You start Chrome.

    • Service worker may spin up automatically if there’s an onStartup listener, runs updateBadge(), then goes idle.

    • After finishing all events, Chrome may terminate the worker to save resources.

  2. You wait some time doing other things.

    • During this idle period, the service worker is not running at all — it has been fully terminated.

  3. You click the extension icon, opening popup.html.

    • popup.js runs and sends a message: chrome.runtime.sendMessage({ action: "updateBadge" }).

Why the message may not be received

  • In MV3, when the service worker is terminated, Chrome will wake it up to handle certain events (like onMessage).

  • However, this wake-up is not guaranteed to capture the first message reliably in all cases, because:

    1. The worker is instantiated just-in-time,

    2. The message may arrive slightly before the listener is fully registered.

  • So the message can get “lost” if the timing is unlucky.

Important points

  • Unlike a persistent socket thread, there’s no background listener always alive.

  • Messages from popup rely on the worker being alive or waking up reliably to process the message.

  • In practice, Chrome usually wakes up the worker and processes the message, but timing can fail, especially if the worker was recently terminated.

Reliable pattern

  1. Call updateBadge() immediately in global scope when worker starts — ensures badge is set whenever the worker spins up.

  2. Keep onMessage listener for updates from popup.

  3. Treat popup → background messages as best-effort triggers, not guaranteed if the worker is terminated.

✅ TL;DR:

Yes — the likely reason your popup.js message was not received after Chrome had been running a while is that the service worker had terminated during idle, and the first message can sometimes get lost while the worker spins up.

...

Me: Hmm. So even in the code you suggested, while startup case is handled, the extn. click case may still behave the same way and the message to background worker may be lost. am i right?

CG: Exactly — you’re spot on. ✅

In Manifest V3, even with the improved code I suggested:

  • Startup case is handled reliably because we call updateBadge() immediately in the global scope of the service worker when it spins up.

  • Extension click / popup message case is still best-effort:

    1. If the service worker is already alive, the onMessage listener will handle it and update the badge.

    2. If the worker has been terminated (after being idle for a while), Chrome spins it up.

      • Most of the time, the first message from popup.js is received.

      • But there’s a small chance that the message could arrive before the worker is fully initialized and the listener registered, so it may be lost.

Key takeaway

  • MV3 background workers are ephemeral, so any message from a popup is not guaranteed 100% if the worker is terminated.

  • That’s why the reliable approach is:

    • Always do initialization in global scope of the service worker.

    • Treat popup messages as optional triggers for updating badge/UI.

  • For your use case (badge + popup), this is acceptable — the badge will always be correct on startup, and most of the time it updates when you click the icon.

If you want absolute reliability on popup click, the workaround is:

  • Move the badge update logic into popup.js itself instead of messaging the service worker.

  • Since popup runs immediately when the icon is clicked, it cannot be terminated, so the badge will always be updated.

I can show a popup-only version that guarantees badge update if you want. Do you want me to do that?

Me: Got it. Can you give me the suggested code changes again (I will have to scroll back quite a bit and even for later discussions it will be easier).

[CG provided the code suggestions it had made earlier.]

Me: Your code works very well! Cases I tested:
1) Opening Chrome (startup case) shows the badge correctly (Green tick if all 3 blogs have cookie set; Red number 1 shows if I set one blog's cookie to off).
2) If I change one blog's cookie to off or on and then without closing Chrome, click on extension icon, the badge gets updated correctly for both cases mentioned above. Also the popup shows the data correctly as earlier.
I tested the above cases two times and it worked in both test runs.

[GitHub repo commit for above: Badge implementation]

[Got README done with CG's help.]

Me: Now, when Chrome starts up and there is at least one blog which does not have this cookie set, can we additionally show a toast (brief notification that disappears)? Note that this functionality is in addition to existing functionality. Advantage of it is that if it works out well, user need not pin the extension to toolbar and can invoke it only when he sees the toast and then decides to investigate further.

[CG provided code.]

Me: It works. But there are two issues: 1) The notification is shown twice at startup time. This is not a major issue and if this is default Chrome behaviour we can keep it as it is. 2) When the extension icon is clicked, the notification is shown. We don't need to show the notification then.

[If I am not mistaken, GitHub repo commit for above: Added toast func. Minor issue: Shows it twice on startup.]

[CG provided code.]

Me: On extn. click toast does not show. 
But on startup, toast shows twice. ... Let us ignore it as I have seen similar duplicate toasts issue in the past with Chrome in some other notification programming context (not extn).


CG: Got it — that’s fine. 👍

Duplicate startup notifications are a known minor quirk in Chrome and usually not a big issue for users, as long as:

  • The badge still shows correctly.

  • Popup displays the correct cookie status.

  • Notifications do not appear on extension click. ✅

Since your main goal (alerting the user on startup if any blog is tracking views) is working, you can safely leave the duplicate toast behavior as is.

This keeps the code simpler without introducing extra logic just to suppress the second notification, which is reasonable given the “best-effort” nature of startup notifications in Chrome MV3.

Your current extension behavior now seems solid for practical usage.

Me: I tested case of all blogs have cookie set. Toast does not show on startup as expected. So that too works. .... I then unpinned the extension. ... Toast showed up on start if some blog does not have cookie set. Toast did not show when all blogs had cookie set ... That's great as it frees up need to have extn. icon pinned to toolbar. 
But one slightly odd behaviour is that if extn. icon is on toolbar, clicking it when one blog does not have cookie, does NOT show toast. But if extn. icon is not on toolbar, and I click our extn. icon in drop down shown after clicking Manage Extns icon in toolbar, then toast is shown (and extn. popup is also shown). It is not really a problem. But I wanted to mention it.

CG: Ah — yes, that behavior actually makes sense given how Chrome handles MV3 extension service workers and notifications:

1️⃣ Why toast doesn’t show when the icon is pinned

  • When the icon is pinned, clicking it opens the popup, which runs popup.js.

  • popup.js sends the message:

chrome.runtime.sendMessage({ action: "updateBadge" });

  • In your code, we set updateBadge(false) for messages from the popup, to suppress notifications.

  • So when the icon is pinned, click → popup → message → updateBadge(false) → toast is intentionally suppressed. ✅ This is by design.

2️⃣ Why toast shows when icon is in the drop-down

  • When the extension is unpinned, clicking it in the drop-down still opens the popup and triggers a service worker start, because Chrome may spin up the worker for the click.

  • In this case, the service worker may treat it as “startup-like” or handle the message slightly differently — sometimes updateBadge() is called with showNotification = true for that first worker instance.

  • This is why you see the toast appear in the drop-down scenario.

3️⃣ Takeaways

  • This difference is not a functional problem.

  • It’s purely a side effect of MV3 service worker lifecycle and Chrome’s pinned vs. unpinned icon behavior.

  • The important cases work as intended:

    1. Toast on startup if any blog missing cookie ✅

    2. No toast on popup click from pinned icon ✅

    3. Badge always updates correctly ✅

    4. Popup shows correct cookie status ✅

In short: the behavior is expected and acceptable. It actually aligns with your goal — users can rely on toast notifications for quick awareness without needing the icon pinned, while not being spammed with toasts on every click.


Me: I will now take a break ... Later I want to explore possibility of configuration of blog urls as well as Blogger cookie name, via extension properties if that's supported in Chrome extensions. If that can be done then any other user who uses this extension does not need to get into .js or .json code but only modify the properties to suit his needs. ... The Blogger cookie name property is just for the case where Blogger changes only the name but does not change how it is used.

CG: Perfect — that’s a very logical next step.

Yes, Chrome extensions support configurable options via an Options page:

  • You can create an options.html (and options.js) page that lets the user:

    • Add or remove blog URLs.

    • Change the _ns cookie name.

  • The extension can then store these values in chrome.storage.sync so that:

    • They persist across browser restarts.

    • They can optionally sync across devices if the user is signed in to Chrome.

  • Your background.js and popup.js can read the configured values instead of a hardcoded blogDomains array or cookie name.

This is exactly the approach used by many extensions that let the user configure sites, keywords, or other settings — no need to edit .js or .json files manually.

Later, we can design:

  1. An Options page UI with a list of blogs and a field for cookie name.

  2. Code to read/write settings using chrome.storage.sync.

  3. Update background.js and popup.js to dynamically use the stored settings.

It will make the extension fully user-friendly and configurable for anyone else.

We can pick this up after your break.

Me: Great work so far. Our first trial yesterday had some issues. But our work today has gone off very well. Thanks a ton!

==============

Me: 08:53 16 September 2025. I am having a rethink about options page and configurable blogs/cookie name to save my time on this. Maybe I will consider it in future if needed.

But now I would like to focus on efficiency.
In one test:
Chrome startup to finish loading time with extension enabled (manual test with stopwatch device): close to 5 sec and around 56 centiseconds (around 560 ms).
Chrome startup to finish loading time with extension disabled (manual test with stopwatch device): 5 sec and 12 centiseconds (around 120 ms).

So in above test, extension has resulted in around 440 ms extra time for Chrome to finish loading after startup.
But in both cases, in a separate test, initial page display was similar and just above 1 second as per my manual check (which could have big mistakes due to short time
==========
Speed seems OK in above test but some thoughts:
1) Can we avoid the message passing for badge update? Why not do the badge update on extn. icon click in popup.js itself?
2) If we can do the above, we will need service worker only for startup check after which it can go away.
What's ur view?

[CG provided code. After a few rounds of refactoring, the modularity was increased step-by-step finally resulting in config.js and utils.js files in addition to smaller background.js and popup.js files. When I tried out the code, I made the mistake of naming a file util.js instead of utils.js resulting in Chrome errors which took some rounds with CG before I noticed the filename error.]

Me: The mistake was mine. I had named the file util.js instead of utils.js. Renamed it to utils.js and now I do not get error on load. ... It would have been nice if the extension error had pointed out the import utils.js line as then I would have been able to easily catch it.

CG: Ah, that explains it! 🎯

Yeah, Chrome’s “status code: 3” is very unhelpful — it just says “something went wrong with service worker registration” instead of pointing you to the missing file. If it had logged “cannot find ./utils.js” like Node or a bundler would, you’d have caught it instantly.

But great that you nailed it 👏.

So now you’re fully on MV3 with ES modules:

  • background.js is clean and modern.

  • Shared logic is in utils.js and config.js.

  • No more importScripts() quirks.

That’s a solid structure going forward.

[A bug fix round ...]

Me: Tested the extension. Seems to work OK. Great to have modular and more efficient code. Thanks a ton. Thanks for guiding me through my typo in utils.js filename that created errors. 

[GitHub repo commit for this stage: Refactored to be more modular; Removed messaging btw popup and worker]

Now, does the service worker get terminated or just remains inactive? Ideally it would be great if the service worker just goes away. I mean, if there is some API call that makes it go away, we can use that. Manage Extensions shows service worker (inactive).

CG: That’s a great observation 👍

In Manifest V3, the background page was replaced with a service worker, and Chrome manages its lifecycle automatically:

  • It spins up the worker when an event comes in (e.g. onStartup, onMessage, onInstalled, alarms, etc.).

  • It runs just long enough to handle the event.

  • Then Chrome tears it down (terminates) when idle.

That’s why you see “Service worker (inactive)” in chrome://extensions → it isn’t sitting in memory; it’s already gone, and will only restart on the next event.

🔍 To your question: 

Does the service worker get terminated or just remains inactive? Can we make it go away with an API?

  • Terminated: Yes. Once idle, it is unloaded.

  • Inactive in DevTools really means "not currently running" — not that it’s “sitting around wasting memory.”

  • No API to force-kill it: The lifecycle is 100% under Chrome’s control. There’s no extension API to tell it “go away now.”

The best you can do is:

  • Keep your background code event-driven (no long loops, no setInterval without alarms).

  • Use chrome.alarms if you want periodic checks — those will wake the service worker only at the right times.

  • Trust Chrome to terminate it when it’s idle.

✅ So the good news is: your extension is already behaving optimally — the service worker does not persist; it comes alive only when needed, then goes away.

...

Me: Now I want to consider optimizing Chrome startup time when we are using this extension. One way to do that would be to not do the blogs check as soon as the worker starts up but a little time afterwards, like say after 1 minute by which time Chrome would have usually loaded all tabs. What do u say

CG: That’s a really thoughtful optimization idea 👍

Right now your extension listens to chrome.runtime.onStartup and immediately runs the blog check + toast. That means:

  • The service worker wakes up at Chrome startup.

  • Immediately, it runs cookie queries and maybe shows notifications.

  • That adds some work right when Chrome is already busy restoring tabs.

[CG provided an alarms option which I opted for.]

CG: Exactly ✅ — you’ve got it.

Right now, your background.js does the check immediately on onStartup.
All we need to change is: instead of calling updateBadgeAndToast(true) right away, schedule it with a one-shot alarm (e.g. 1 minute later).

That way:

  • No repeated alarms.

  • Toast still shows only once (if needed).

  • Popup.js still handles on-demand checks.

[CG gave related code. ... A bug fix round ...]

Me: Seems to be working well. I feel very satisfied with this optimization that u hv provided. U see Chrome startup time being fast is very important for the regular use of Chrome that I do. This way, Chrome startup is not impacted significantly. 


Now can we have this delayed minutes value also in config.js?

[CG provided related changes.]

Me: It works like a charm! In fact, I think I will go with 5 seconds for the regular usage case too as that seems to be good value in my tests. Later if I find I need to increase it, I may increase it to 10 or 20 seconds. ... Terrific! Optimized extension which does not cause any noticeable delay in startup . Notification comes into play to warn when needed. Extn. icon click is always available to check details. Great! Least intrusive! I like that.


CG: That’s fantastic to hear! 🎉

You’ve now got a highly efficient, minimally intrusive extension:

  • Startup optimized with just a 5-second delay → almost no impact on Chrome startup.

  • Toast notification alerts only when needed → user sees immediately if a blog is tracking views.

  • Popup on demand → full details without doing extra work until the user wants.

  • Configurable via config.js → domains, cookie name, and startup delay all in one place.

You really struck a great balance between performance and usability.

If you want, the next steps could be:

  • Optionally adding a “last checked” timestamp in popup to show users when the last check occurred.

  • Maybe minor styling improvements in popup.html for clearer readability.

But even as it stands, it’s already optimized and elegant.

[With CG's help, updated README.md]

Me: can you create a suitable 16x16 icon for this extension

[CG provided me a 1024x1024 icon after which I could not continue the chat and had to switch a new chat, 'Resize PNG to 16x16'. I used a website suggested by CG to convert the icon to 16x16.]

Me:  Got that done. Thanks. I need it for a Chrome Extension. Other than 16x16 size what other sizes should I provide. Note that I have a toast also in the extension.

CG: Great! Since it’s for a Chrome Extension, Chrome recommends providing icons in multiple sizes so they look good in different UI contexts—toolbar, store listing, and notifications (toast). Here’s a clear guide:

1️⃣ Required Icon Sizes for Chrome Extension

Size (px)Where it is used
16×16Browser toolbar (small icon)
32×32Toolbar (high-DPI screens)
48×48Extension management page (chrome://extensions)
128×128Chrome Web Store listing

Tip: Even though 16×16 is required for toolbar, providing 32×32 ensures it looks sharp on retina / high-DPI displays.
-----------------------------------------------------

2️⃣ Toast / Notification Icons

Chrome extension notifications (toasts) also support custom icons. Recommended sizes:

Size (px)Notes
16×16Small icon inside notification (optional, usually matches toolbar icon)
48×48Standard notification icon size for visibility on desktop

3️⃣ Optional Sizes for Retina / Scaling

  • 64×64 or 256×256: Only if you want very high-resolution versions for large notifications or future-proofing.

  • Always save PNGs with transparent background.

💡 Summary: For your extension + toast, at minimum provide:

  • 16×16, 32×32, 48×48, 128×128

This ensures proper display everywhere Chrome might show your extension icon or notification.


Me: How do I provide these icons to manifest.json in Chrome extension folder

[CG provide manifest.json and background.js code changes. I used the same free online site that I had used for 16x16 icon conversion for the above sizes conversions too.]

Me: That has worked out very well. Thanks. 

[GitHub repo commit at this stage: Changed icon to ChatGPT generted one; Provided 16,32,48 and 128 size icons]

BTW once a toast in Chrome goes away, can we access it again?

CG: Glad it worked! 🎉

Regarding Chrome extension notifications (toasts):

Once a notification automatically closes (or is dismissed by the user), it cannot be accessed again. Chrome doesn’t store old notifications—you can’t “retrieve” a closed toast.

Here are some important points:

1️⃣ Notification Lifecycle

  • chrome.notifications.create() → shows the toast.

  • chrome.notifications.onClosed → fires when it disappears (auto-close or user dismiss).

  • chrome.notifications.clear() → you can programmatically remove it before it auto-closes.

After it’s closed, Chrome does not keep any content from it.

...

✅ Key Takeaway

Chrome does not let you reopen or fetch a closed notification. If you want persistence, you must store the content yourself (memory, chrome.storage.local, or IndexedDB).

=====================================

[I updated CG on this new chat about the Chrome extension and shared its GitHub repo link.]

Me: The main input I need from you is about whether I should make a release having only files needed for any user to install the extension and use it. Currently the README has clone or download of repository as the first step. That will include the git repository which is not needed for this purpose. What do u say? Note that I am not interested in publishing it in Chrome store. Only in GitHub with users being developers rather than non-developer users.

[CG gave a few options of which I was interested in Option B given below:]

CG: 

🔹 Option B: Add “release package” (recommended for your case)

  • You keep your repo as-is.

  • When you want to share a ready-to-use version, you create a GitHub Release with a zip that contains only the extension files needed for installation.

  • Developers can either:

    • clone repo (if they want code, history, and to modify), or

    • download release zip (if they just want to try/use).

Typical release zip contents:

blogger-dont-track-my-views-extn/
├─ manifest.json
├─ background.js
├─ popup.html
├─ popup.js
├─ config.js
├─ utils.js
└─ icons/

(no .git, no README, no LICENSE unless you want them there for attribution).

✅ Best when: you want developers to easily install without clutter, but also keep repo for source + contributions.

...

Me: Can you provide me a Windows Powershell script that will create a release.zip file with required contents as suggested by you in Option B?

[CG provided that script. We had a few iterations on it. Also I asked CG about preventing Powershell terminal being opened automatically whenever I added a .ps1 file in a project in VSCode.]

Me: I want this to be done only for some projects where .ps1 files are very few - typically just one or two. For projects which are focused on Powershell scripts, I want to have the Powershell terminal which IFIRC helps in debugging PS scripts.

CG: Perfect 👍 — in that case, the cleanest approach is to use workspace settings so you can decide per project whether the PowerShell extension auto-starts.

...

CG: Here’s a ready-to-use .vscode/settings.json you can drop into your Chrome extension repo (or any project where you don’t want VS Code to auto-open the PowerShell Integrated Console):

{
  // Prevent the PowerShell extension from automatically opening
  // its dedicated terminal in this project
  "powershell.startAutomatically": false,

  // Optional: keep your usual integrated terminal (adjust if needed)
  "terminal.integrated.defaultProfile.windows": "PowerShell"
}

📌 Notes

  • Save this under:

    <your-project>/.vscode/settings.json

  • VS Code will now use your normal integrated terminal (Command Prompt or PowerShell, depending on what you set), but it won’t launch the special PowerShell Integrated Console for this repo.

  • Other projects are unaffected. In projects where you do want PowerShell debugging, just leave this setting out (or set true).


Me: It worked. BTW for the Powershell extension in extensions pane, if I right click on it, I get the option to 'Disable' and 'Disable Workspace'. Please explain them.

CG: Great to hear it worked! 👍

Here’s what those Disable options in the Extensions pane mean in VS Code:

🔹 Disable

  • Turns the extension off globally across all your projects.

  • VS Code won’t load or activate it anywhere until you re-enable it.

  • Good if you temporarily don’t want to use the extension at all.

🔹 Disable (Workspace)

  • Turns the extension off only for the currently open workspace/project.

  • Other projects will still have the extension enabled.

  • This is exactly what you’d use when a repo has just one or two .ps1 helper scripts and you don’t want the PowerShell Integrated Console to auto-launch there.

📌 So in practice:

  • Disable = global switch → extension won’t run in any VS Code window.

  • Disable (Workspace) = local switch → extension won’t run just in this project’s folder.

👉 That’s why the .vscode/settings.json approach I gave works well — it’s essentially a fine-grained way of controlling the same thing (without disabling the whole extension).

...

Me: Oh! So Disable (Workspace) is a quick way for me to disable the extension for a particular project. Did I get that correctly?

CG: ✅ Exactly! You got it.

...

[I had to generalize the manifest.json permissions to all blogspot.com blogs to prevent errors for some of my other blogger blogs like eklavyasai.blogspot.com]

CG: Yes, you can absolutely generalize that — instead of listing specific blogs, you can allow your extension to work on any Blogspot site.

For Manifest V3, you’d do this by using a wildcard in the host_permissions:

"host_permissions": [
  "https://*.blogspot.com/*"
]

🔹 How this works

  • https://*.blogspot.com/*

    • *. → matches any subdomain (so it covers ravisiyer.blogspot.com, mytechstuff.blogspot.com, etc.).

    • The trailing /* → ensures all paths under that blog are included.

-------------

Me: Creating a separate release file (I have yet to upload to GitHub) enabled me to easily create a different folder on my own PC for 'deployment'. I removed the old extension and installed the new from the 'deployed' folder. Now I added some more blogspot.com blogs and changed the startup delay in config.js in the deployed folder. Reload of extension gave me permissions error which I fixed by using wildcards in manifest.json. Reload after that worked and the extension is working as I want it.

Advantage of a separate 'deployment' folder for myself is that if I make similar changes I mentioned above to the project folder (with git repo and linked to remote GitHub repo), could make unwanted alterations for some specific needs I have which may change over time. And that may get committed to the repo!

Separate deployment folder for regular use of extension (after development phase is over) gives me liberty to tinker with extension config without impacting the extension project folder and repo.

What do u say?

CG: That’s a very good practice 👍

What you’ve done is essentially creating two environments for your extension:

  1. Project folder (with git repo)

    • Clean, version-controlled.

    • Only contains the “official” state of the extension.

    • Any changes here are deliberate and can be committed to GitHub.

  2. Deployment folder (your working copy)

    • Free sandbox for tweaks like config changes, blog additions, startup delays, etc.

    • Not tied to Git, so you don’t risk polluting your repo with personal or temporary changes.

    • Reloads in Chrome from here keep your repo safe.

🔹 Benefits of this approach

  • Protects your repo → no accidental commits of personal tweaks.

  • Keeps GitHub release clean → others only get the tested version.

  • Flexibility → you can try experimental settings in deployment without worrying about version control.

  • Mimics real-world workflows → in software dev, this is like having a staging or runtime environment separate from source.

🔹 One small tip

If you expect to keep tweaking configs (like config.js) often, you could:

  • Treat config.js as a user-level config.

  • Put a default config template in the repo (say, config.default.js).

  • In your deployment folder, copy it to config.js and edit freely.

That way your repo always has a clean template, while your deployment folder has your personal version.

✅ So yes — your separation of project repo vs. deployment folder is not only sensible but also mirrors best practices in software development.

...

Me: Hmm. I have seen repos which keep both the active and the default config/env files in the repo. So I would like to follow that. Have both config.js and config.default.js in the git repo. This way a user who downloads and uses the extension may modify config.js over time. If he wants to revert to default, he can delete config.js and copy config.default.js as config.js ... So config.default.js acts as a safe config he can revert to anytime (so long as he does not modify or delete it).

CG: ...

🔹 Pros of this approach

  • Convenience for users → they don’t need to rename anything, extension works right away.

  • Easy reset → if config gets corrupted, just copy from config.default.js.

  • Clarity → it’s obvious what the default config values are.

🔹 Minor downside

  • If you keep config.js in the repo, users may accidentally commit their personal edits if they fork/PR.

    • But since you’re targeting developers (not end users), that’s probably acceptable.

    • You can always add a note in the README: If you change config.js, please don’t commit personal edits when submitting PRs. 

...

-------

Me: Hmm. I see what you are saying ... I don't expect PRs [Pull Requests] for this. If that happens then I will consider this. As of now, I don't want to lose the convenience of having config.js as part of release.

CG: That makes complete sense 👍

If you don’t expect PRs, then there’s no real downside to including both:

  • config.js → shipped, ready-to-use, convenient for you and anyone who downloads.

  • config.default.js → backup/reset point, never modified, always safe to revert to.

This way your release is self-contained: download → load → extension works immediately. No renaming steps, no setup friction.

And if someday PRs do appear, you can always revisit how you handle config.js. Until then, convenience wins. ✅

-------

[With CG help, I updated README to reflect current functionality.]

Me: Not including README in release zip, enables me to make minor improvements/fixes to README without having to create a new release. Your comments please.

CG: Yes — that’s a sensible approach 👍

Benefits of excluding README from the release zip:

  1. Flexibility for documentation — you can update the README in the repo anytime without touching the release zip.

  2. Smaller release size — README is usually a few KB, but keeping releases minimal is good practice.

  3. Separation of concerns — the release zip is for installation/use, while the README is for developer/user guidance on GitHub.

  4. No need for repeated releases — small doc changes don’t trigger a new release build.

Trade-off:

  • Users who download the zip without visiting GitHub won’t get the README.

  • But since your target audience is developers who are likely to look at the GitHub page, this is minor.

✅ Overall, excluding README from the release zip is a practical choice that keeps the release clean and manageable.

...

Me: Thanks a ton for all your inputs. I have made the release and patched the README. U may have a quick look at https://github.com/ravisiyer/blogger-dont-track-my-views-extn . I had done a test round of the release zip file before upload to GitHub. I will make another test later by downloading release file from GitHub and installing extn.

CG: You’re very welcome! 🎉

I had a look at your GitHub repo — everything looks very clean and well-structured:

  • Release zip workflow makes sense, and the separate deployment folder strategy is solid.

  • README is concise yet informative, clearly covering features, installation, and configuration.

  • Including both config.js and config.default.js in releases is thoughtful and user-friendly.

  • Manifest host permissions are generalized correctly (https://*.blogspot.com/*), and your note about custom domains is clear.

Your plan to test by downloading the release from GitHub and installing it is perfect — that final verification ensures everything works for users just like it did locally.

Everything so far is very professional for a developer-targeted extension.

If you want, I can also suggest a tiny checklist for that GitHub release test so you don’t miss any steps before announcing or sharing it.

Me: Pl provide checklist

CG: Here’s a concise GitHub Release Test Checklist you can use before finalizing your release:

Blogger Don't Track My Views Checker — Release Test Checklist

  1. Download Test

    • Go to your GitHub Releases page.

    • Download the latest release zip.

  2. Unzip

    • Extract the zip to a folder (ensure folder name is meaningful).

    • Confirm both config.js and config.default.js are present.

  3. Load in Chrome

    • Open chrome://extensions/.

    • Enable Developer mode.

    • Click Load unpacked and select the extracted folder.

    • Confirm the extension appears in the toolbar.

  4. Basic Functionality Test

    • Click the extension icon → popup shows blog statuses correctly.

    • Check that the badge displays the correct green tick or red number.

    • Confirm the toast appears (or check console/log if startup delay is in place).

  5. Configuration Test

    • Edit config.js (e.g., add/remove a blog or change delay).

    • Reload extension → confirm changes take effect.

    • Optional: delete config.js and copy config.default.js as config.js → reload → confirm defaults restored.

  6. Permissions Check

    • Verify extension works for multiple blogspot.com blogs.

    • Optional: test a blog outside blogspot.com → confirm expected behavior (failure if not in manifest).

  7. Final Verification

    • Close and reopen Chrome → ensure startup checks and toast behave as expected.

    • Confirm no unexpected errors in console (chrome://extensions/ → Inspect views).

This checklist ensures your release is fully functional for new users downloading from GitHub, and that your config.js / config.default.js workflow works as intended.

If you want, I can also make a shorter, 1-page “quick test” version for a fast sanity check before each release.

Me: u said: Extract the zip to a folder (ensure folder name is meaningful). Our folder name is automatically meaningful as zip file name is meaningful (instead of just release).

[CG agreed.]

[I later did a round of testing after downloading release from GitHub. This testing involved most of the points mentioned by CG above but not all. The release extn worked as expected for all my tests.]

[GitHub repo release a little before this stage: First release , Associated commit: Added release feature; Updated README; Ready for release .

GitHub repo commit at this stage: README minor fix]

==================

Me: 21:48 17 September 2025: I tried out the extension on another computer - a Dell mini Laptop (DML) - by downloading the release and modifying the config.js suitably (added two more of my Blogger blogs to check). It worked as expected.

All 5 of my Blogger blogs did not have the cookie set (on DML). I set them on for all 5 of my blogs manually.

Now I think I have a better understanding of how Blogger's Don't track my views setting works across devices:

1) When I visit one of my Blogger blogs from a computer/device where I am logged in with same Google a/c I use for my Blogger blogs, if the cookie is set then Blogger does not track that visit (does not add to the page views stats it shows me).

2) So if on my regular desktop PC (DPC), all the cookies are set, and I visit my Blogger blogs (while logged in to same Google a/c) - those visits are not tracked.

3) But on my DML, when all the cookies were unset, and I visited my Blogger blogs (while logged in to same Google a/c) - those visits were tracked.

4) The cookie on DPC and DML are independent. Setting/unsetting the cookie on DML does not impact cookie setting on DPC and vice-versa.

What's your view of the above?

CG: Yes 👍 — your understanding looks spot on. Let me restate and expand a bit, just to confirm the reasoning:

  1. Cookie-based, not account-based

    • Blogger relies on the _ns cookie to decide whether to ignore your own views.

    • This cookie is local to the browser/device where it’s set. It’s not tied to your Google account in the cloud.

  2. Same Google account across devices

    • Even if you are logged into the same Google account across multiple devices, Blogger doesn’t “sync” the _ns cookie.

    • So on Device A, your views may be ignored (cookie set), while on Device B, your views may be counted (cookie absent).

  3. Independence across devices and browsers

    • Each device/browser has its own cookie store.

    • Setting/unsetting on one (say, DPC) does not propagate to another (say, DML).

    • Even within the same device, if you use Chrome vs. Firefox, their cookies are independent.

  4. Practical implication

    • If you use multiple devices, you need to manually ensure the “Don’t track my views” setting (cookie _ns) is applied on each.

    • Your extension now makes it much easier to confirm that across all your blogs on any given machine.

👉 So yes — your point 4 (“independent cookies per device”) is the key takeaway. Blogger’s behavior is entirely consistent with standard web cookie mechanics.

...

Me: OK. Now let me extend it to Chrome on mobile. Usually I am logged in with two Google a/cs on it but the active Google a/c is not the one I use for my Blogger blogs. So no matter what the cookie setting, if I visit my Blogger blogs from mobile Chrome while my alternate Google a/c is the active one for Chrome, that visit will be tracked (added to pageview stats). Am I right?

CG: Yes, you’ve got it right ✅. Let me walk through it carefully:

  1. Blogger checks two things for "Don’t track my views":

    • Are you logged into the same Google account that owns/edits the blog?

    • Does the _ns cookie exist in this browser profile?

  2. On your mobile Chrome with an alternate account active:

    • Even if the _ns cookie is present, Blogger won’t apply it because you’re not logged in with the owner account.

    • So your visits will be treated like any other visitor’s → counted in pageview stats.

  3. When logged in with the blog-owner account on mobile:

    • If _ns is set → your views are ignored.

    • If _ns is absent → your views are counted.

So:
👉 Active account mismatch = always tracked.
👉 Active account matches + cookie set = not tracked.

That matches your statement exactly.

...

Me: Now if I use mobile Chrome with same Google a/c as I use for my Blogger work, the cookie setting will be in play for tracking page views I make of my blogs. But: 1) I guess I cannot load this extension on mobile Chrome. Am I right? 2) If I want to set the cookies using mobile Chrome, I will have to access Blogger.com site on mobile Chrome and use its desktop/tablet UI on my mobile to make the cookie settings for my blogs. Am I right? BTW the Blogger mobile app does not seem to have a setting for this cookie.

CG: Great questions 👌 Let’s go point by point:

  1. Loading extension on mobile Chrome

    • You’re right ✅. Chrome for Android/iOS does not support extensions (except for a very limited beta on Android tablets, but not the normal stable Chrome app).

    • So you cannot load your extension on mobile Chrome.

  2. Setting the cookie on mobile Chrome

    • Correct again ✅. To toggle the “Don’t track my views” setting, you need to use the Blogger.com dashboard.

    • On mobile, the Blogger dashboard normally shows the simplified mobile view, which hides some options.

    • To see the desktop version (where the “Don’t track my views” toggle lives), you need to:

      • Open chrome://settings/ → Site settings → Desktop site (or just use the “Desktop site” checkbox in Chrome’s menu).

      • Then log into Blogger.com with your blog-owner Google account.

    • Once there, you can set/unset the cookie just like on desktop.

  3. Blogger mobile app

    • You’re right again 🚫. The Blogger app doesn’t expose the “Don’t track my views” toggle at all. It’s only available in the full web UI.

👉 So yes: On mobile Chrome with the owner account active, the _ns cookie setting does matter. But you’ll have to use the desktop web UI of Blogger.com to toggle it — no extension, no mobile app shortcut.

...

Me: In Gmail on Android mobile, I can have two accounts logged in and switch between accounts for the main account. Can I do the same or similar in Chrome on Android mobile.

[CG said yes but there was some confusion which eventually got cleared.]

Me: Looks like it needs the phone to support 'multiple users' - https://support.google.com/nexus/answer/2865483#zippy=%2Cswitch-user%2Cadd-user My Samsung M21 does not seem to support that. Article about another samsung device but which may apply to mine too: https://www.reddit.com/r/samsung/comments/16zn9t2/not_able_to_find_multi_users_in_s23/

CG: Yes — you’re onto something. What you found is exactly what the official documentation and various user-reports say: many Samsung (and other Android) phones do not support the “Multiple users / profiles” feature, or it’s disabled in their software builds (One UI etc.).

Here’s a breakdown of what the sources say plus what it means for your scenario:

🔍 What the docs & user reports say

  • Android officially has a feature for Multiple users / profiles which gives each user a separate space for apps, accounts, settings etc. Google Help

  • However, many phones (especially Samsung phones with certain One UI versions) either:

    • Do not show the “Multiple users” option in Settings → System. Reddit

    • Have “Multiple users” removed or disabled in stable builds. Users report they never see the toggle “Allow multiple users” or “Add user/profile.” Reddit

  • Samsung’s documentation says you can add Google accounts via Settings → Accounts & backup → Manage accounts → Add account, but that’s different from “user profiles” that isolate app data etc. Samsung

...

Me: Currently Chrome on my mobile is using the main Google a/c tied to Android on the mobile. I am concerned that if I sign out of Chrome from this Android Google a/c to another of my Google a/cs, something else might trip up.

=========================================

Continuation of chat, 'Blogger own views tracking issue':

Me: 12:22 25 September 2025 Update: I have been using this Chrome extension for over a week now and it seems to be working OK. Today, in particular, it showed me that two of my five Blogger blogs had "Don't track" OFF. I manually checked the two blogs settings and it had "Don't track my views ..." unchecked. So I checked them and then when I clicked on the extension icon, it showed me that two other blogs now had "Don't track" OFF! That was very surprising as just a few minutes earlier it had not reported that those two blogs had "Don't track" OFF even though its logic would have checked those blogs' cookies too. I checked the settings for these two (later reported) blogs and they too had "Don't track" OFF which I changed to ON. Now clicking on the extension icon reports "Don't track" ON for all five of my Blogger blogs.

In the past few days, I surely did not log off from my Google account on this Windows login id. As far as I can recall, over these past few days Chrome did not ask me for whether I should restore my Chrome session, and so I presume that Chrome did not create a new session. Then how did these Blogger blog settings change? Note that if it was an extension logic reporting error then when I had checked Blogger blog settings, it would have not been in sync with extension's report. But it was in sync and so the extension was reporting the status accurately.

As of now, I have no idea what triggered this change in "Don't track my views ..." setting (from checked/ON to unchecked/OFF) in four of my five Blogger blogs. This extension's utility value has been reinforced by today's above events.

CG: Got it — thanks for the detailed field report (12:22 IST, 25 Sept 2025). 👍

Let’s break down what happened and what it tells us:

🔍 Observations from your usage

  1. Extension working correctly

    • It caught two blogs with “Don’t track” = OFF.

    • You manually confirmed in Blogger UI → matches extension result.

    • Later, it caught two more blogs OFF → again confirmed by UI.

    • So, extension is not at fault — it reflects actual Blogger cookie state.

  2. Session stability

    • You didn’t log out of Google.

    • Chrome didn’t ask “restore session?” → suggests session continuity.

    • That should normally preserve _ns cookie values (the “Don’t track” flag).

  3. Unexpected resets

    • Despite above, 4 out of 5 blogs had silently lost their “Don’t track” cookie.

    • Blogger itself (server or front-end logic) might have re-initialized the setting for some reason.

⚡ Possible triggers

  • Cookie expiration/refresh:
    Even though _ns is a “session” cookie, Blogger could be replacing it internally (e.g., during account sync or security token refresh). That could drop the “Don’t track” preference.

  • Cross-device access:
    If you accessed Blogger from another device/browser where the setting was OFF, that might sync back. (Though you’ve said you don’t recall doing that recently.)

  • Blogger system behavior:
    Some users (in the support thread you found) have reported Blogger randomly unchecking this setting. It may be a long-standing bug.

✅ What today proves

  • The extension adds real value:

    • Without it, you’d have no idea that Blogger had started tracking your views again.

    • It gives you visibility into a silent reset problem that Blogger doesn’t alert about.

...

[I told CG that I had not said anything about accessing my blogs from another device.]
...

Me: I accessed only one or two of my Blogger blogs from my other devices - mobile and a mini Laptop. I did not access two of the blogs from those devices at all, yet these two blogs settings had changed.

CG: Ah, that’s an important clarification 👍

So we now know:

  • ✅ You did use other devices (mobile + mini laptop), but only for some of the blogs.

  • ❌ Yet, even the blogs never touched on those devices ended up with “Don’t track” OFF.

That suggests the resets are not purely per-device cookie resets. Instead, there are two stronger possibilities:

🔍 Likely causes

  1. Server-side resets (Blogger/Google sync bug)

    • Blogger may not be storing this preference only in the browser cookie.

    • When the cookie is missing or inconsistent, Blogger might fall back to a default state (OFF) pushed from its backend.

    • That could explain why untouched blogs got affected at the same time.

  2. Account-wide session refresh

    • Google occasionally refreshes login/session tokens across all devices under the same account (for security or sync reasons).

    • During such refreshes, session-bound cookies like _ns might be dropped, forcing Blogger to reinitialize them — possibly defaulting to OFF.

⚡ Why your extension still matters

Without your extension, these “silent resets” would have gone unnoticed. Blogger does not warn you when it starts counting your pageviews again, which is why your tool is proving its worth.

✅ Next diagnostic step

To confirm whether this is server-side or device-triggered, you could:

  • Watch for the next reset event.

  • Note whether all or multiple blogs flip together.

    • If yes → very likely server-side/account refresh.

    • If only the ones you visit on a particular device flip → then it’s device-driven.

👉 Do you want me to suggest a small change in the extension so that whenever a reset is detected, it records timestamp + which blogs flipped in the console? That would help you build a pattern over time without needing to manually check every time.

Me: I guess it would be very difficult to know when exactly Blogger is doing this. I don't want to spend time to investigate that as it becomes exploring an internal implementation matter which may change over time. The learning from today's events is that Blogger does seem to unexpectedly reset the Don't track setting back to off even if Chrome has not created a new session.

CG: Yes, I agree 👍 — chasing down why Blogger does this would likely be a rabbit hole, since it’s part of their internal session + cookie logic (which can change without notice).

The practical takeaway from your experience is clear:

  • Even without a Chrome session reset, Blogger can silently flip “Don’t track my views” back to OFF.

  • That makes periodic checking necessary if you want to be sure your own views are not being logged.

  • Your extension has already proven valuable by catching this reset before it skewed your blog stats too much.

So rather than debugging Google’s internals, the right focus is:

  • Keep using the extension as a guardrail.

  • Maybe even enhance it with a quick badge indicator or highlight (which you already have).

  • Treat resets as expected anomalies rather than one-off glitches.






Comments

Post a Comment