Is there a way to freeze an extension during the browser opening?

[Robbi]

Hi everyone,

is there a way to access the application panel objects (localStorage, indexedDB, etc.) of an extension without activating the extension itself?

Let me give you a practical example: I have an extension that resets some localStorage variables only once at the beginning of the new day or in any case if it realizes that the last day in which the extension was active is before today.

So if I open the browser and that extension is enabled the values of those variables have flown away. If the extension is disabled, as soon as I re-enable it I still lose these values.

So is there a method to freeze the execution of the extension while having access to the storages panel?

Some command line like  chrome.exe -freeze-ext-id="xxxxxxxxxxxx" ?

TIA

[Oliver Dunk]

Hi Robbi,

I'm not aware of a flag like that, so I think you'll need to come up with your own mechanism for this.

Have you looked at using a non-persistent background page (MV2) or a service worker (MV3)?

In both cases, these will only start up when the browser does if they are listening to an event which fires.

To debug the storage, you could open an extension page - these can access the same storage areas but opening one doesn't wake the background.

Another option could be a mechanism built in to your extension - for example, skip the logic if a local HTTP server responds to a request with a certain response, or if some other condition is true.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/ed69c51d-df50-4ff1-9b3e-f366f5aed6cbn%40chromium.org.

[Deco]

The way Chrome instantiates extensions does not have a way to freeze extensions, they are only disabled and enabled (respectively according to the background state). This even applies on where a whitelist permission has been hit for the browser to forcefully switch off the extension until user consent has been granted.

Oliver's suggestion of using a service worker is an ideal solution to this problem.

Cheers,

Deco

--

[Robbi]

Ok, thanks for your answers.

Unfortunately I'm dealing with a persistent background extension that I'm migrating to mv3.

In that variable I save a piece of html code that I get as a response of a fetch.

This response is different every day; so the only way to view that variable could be to stop the flow before it gets to the reinitialization line :-(

I've seen there is a flag that allows to automatically open the devtools window for each open tab.

It would also be nice to have a flag that adds a "debugger" line to the top of both the current tab and the bacground (maybethis isn't possible for various reasons).

[wOxxOm]

If the extension is unpacked then you can just edit the script file and comment out or remove that code temporarily, start the extension, open devtools for the background script, set a breakpoint on the first line (or  add `debugger;` statement), restore the original code, press F5 or Ctrl-R to reload the background script.

If the extension is from the web store you can make a local copy of its directory elsewhere, remove _metadata in the copy, install the copy, which would replace the original extension and preserve the storage because the extension's id will be the same thanks to "key" in manifest.json. Then debug it as described above for the unpacked extension.

[Robbi]

The second one (web store).

@wOxxOm, you're a genius!

Anyway it's too late 'cause I lost that value, but I must remember this method for the future!

Thanks.