Stale MV3 service worker with Chrome --load-extension

[Gaurang Tandon]

Background: When testing my extension with Selenium, I launch Chrome and load the extension using the --load-extension flag on Chrome. The tests were failing in MV3 occasionally, and it seemed to me my code is wrong, when really the old/stale code was running each time I relaunched Chrome.

Problem: I have noticed that the MV3 service worker file does not refresh when (re-)launching Chrome with --load-extension. This is not the case with MV2 extensions, so this feels like a regression to me. And this issue occurs even if you launch the browser normally from CLI (without Selenium).

I don't know if this is the intended behavior with MV3, or is it a bug, or am I making a mistake. But would be nice to hear any suggestions or workarounds for this.
 
Steps to reproduce the staleness issue. I have reproduced it with Chrome Dev today:
 
1. Download the sample extension from this link: https://drive.google.com/drive/folders/1TcTc12GFBg0DRQRcYgxAqNyYQCGMAVkr?usp=sharing  
2. Do `cp mv2.json manifest.json` to load extension as MV2 first  
3. Run the command: `google-chrome --new-window --load-extension=<abs-path-to-ext>` (for powershell: `& 'C:\Program Files\Google\Chrome\Application\chrome.exe' --new-window --load-extension=<abs-path-to-ext>`)  
4. Navigate to chrome://extensions and check integer value in extension logs. Now close the window, and then update the integer in background.js file.
5. Repeat step 3-4 multiple times, each time you'll notice the updated integer in your console log.
6. Now do `cp mv3.json manifest.json` to make the extension an mv3 extension.

7. Repeat steps 3-4 multiple times. You'll notice that even if you update the integer, it's value is still old in the logs.

Additionally: I understand that per service worker lifetime, a service worker is only loaded/launched when its registered event listener is triggered. However, I feel this is unrelated to service worker lifetimes because we're doing a fresh browser launch (close and reopen), with a flag specifying the extension directory. So the browser should read and load the latest files from the extension directory, like it was doing in MV2. I don't understand this behavior of not loading latest files in MV3 case.

[wOxxOm]

Definitely a bug which you can report on https://crbug.com. Probably caused by the fact that service workers are registered in a global registry so Chrome mistakenly retains the old registration and runs it on the next start of the browser. In ManifestV2 there was no such registry.

[Jackie Han]

A workaround is clearing the service worker directory of Chrome before launching Chrome.

For example, rm -fr /Users/username/Library/Application\ Support/Google/Chrome/Profile\ 1/Service\ Worker/* on Mac. You can get Profile Path from chrome://version/.

--
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/7d2dade8-f839-4985-b80f-add5a35a8fe3n%40chromium.org.

[Gaurang Tandon]

Thanks to both of you for your helpful comments.

I have logged an issue on crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1346291 I would be surprised if this issue hasn't been reported earlier, as I encountered it as soon as I started running automated testing on my MV3 extension a week ago.