Extension's service worker seems to be getting cached by some machines

3 views
Skip to first unread message

Allen Yang

unread,
8:26 PM (2 hours ago) 8:26 PM
to Chromium Extensions
Hi all,

Short version: I've been iterating on a Chrome extension, and I'm seeing that the extension behaves differently on different machines and even different Chrome profiles on the same machine, when the extension was installed by those profiles at different points in time. Specifically, the difference in behavior is notable in relation to dynamicNetRequests not working consistently. It's leading me to believe that the browser is caching or otherwise using a stale version of the service worker script in the extension. I've tried clearing the profile's cache, uninstalling + reinstalling the extension, renaming the script, and restarting Chrome - none of those work. 

Has anybody else bumped into this issue? Is there a way to forcibly clear any old version of a service worker script from a profile?

=====

Longer version, in case there's specifically an interaction with declarativeNetRequests:

I've written a Chrome extension that watches for the user typing in a certain URL pattern and applies a declarativeNetRequest rule. Specifically, the extension detects if the user types in a go-link of the format "go/blah", and handles a redirect. Over time, I've shifted how the declarativeNetRequest is declared.

The simplest version of the rule I want that should work is a static rule, declared here in manifest.json:
```
"declarative_net_request": {
        "rule_resources": [
            {
                "id": "ruleset_1",
                "enabled": true,
                "path": "rules.json"
            }
        ]
    },
```

And rules.json has:
```
[
    {
        "id": 1,
        "priority": 1,
        "action": {
            "type": "redirect",
            "redirect": {
                "regexSubstitution": "https://thisismydomain.com/go/\\1"
            }
        },
        "condition": {
            "regexFilter": "^https?://go/(.*)",
            "resourceTypes": ["main_frame"]
        }
    }
]
```

At one point, I also tried using a dynamic rule. I have a background service worker script declared in manifest.json, and that script did something like:
```
const RULES = [{
        id: 1,
        priority: 2,
        action: {
            type: 'redirect',
            redirect: {
                regexSubstitution: "https://thisismydomain.com/go/\\1"
            },
        },
        condition: {
            regexFilter: '^https?:\/\/.+google.com\/[^q]*q\=go%2F([^&]*)&.*',
            resourceTypes: ['main_frame', 'sub_frame'],
        },
    },
    {
        id: 2,
        priority: 1,
        action: {
            type: 'redirect',
            redirect: {
                regexSubstitution: "https://thisismydomain.com/go/\\1"
            },
        },
        condition: {
            regexFilter: "^https?://go/(.*)",
            resourceTypes: ['main_frame', 'sub_frame'],
        },
    }
];
chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: RULES.map(r => r.id),
  addRules: RULES,
});
```

In past versions of this extension, I had just the static rule, then just the dynamic rules, and now both static and dynamic (as I'm trying to debug the situation). As mentioned in the "short version" above, this extension installed on different Chrome profiles / different machines acts inconsistently - some machines are stuck with the behavior from older versions - even when chrome://extensions shows that it's the same published version of the extension that is in use.
Reply all
Reply to author
Forward
0 new messages