Downgrading from V3 to V2

[Amhed Herrera]

Are there any known side effects/bugs from downgrading from V3 to V2?

My team has a published extension running on Manifest V3. We're temporarily downgrading to V2 because we need to persist encrypted data on the long-running background service. We're planning to migrate to V3 as soon as chrome.storage.inMemory is supported/on the stable release. 

This works:

- Install V3 version using Load Unpacked. OK

- Uninstall extension

- Rebuild using V2

- Install V2 version using Load Unpacked. OK

This doesn't:

- Install V3 version using Load Unpacked. OK

- Rebuild using V2

- Go to chrome://extensions and reload

- Extension works until a message is passed between background service and popup/tab. Then chrome crashes. 

Anyone know of anything I need to clear to allow my users to upgrade in place without having to uninstall/reinstall? I've also tried clearing all storage manually on the extension but can't figure out why this happens

Here's the console output from running via `/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging --v=1`

[1020/204648.635248:WARNING:process_memory_mac.cc(93)] mach_vm_read(0x7ffee0e2f000, 0x2000): (os/kern) invalid address (1)

[1020/204649.039666:WARNING:crash_report_exception_handler.cc(240)] UniversalExceptionRaise: (os/kern) failure (5)

zsh: illegal hardware instruction  

[Amhed Herrera]

It appears there's an open listener on chrome.windows.onRemoved that still points to the previous service worker reference. This explains why uninstalling / installing again makes the problem go away. 

I've attempted to clear the event listeners via chrome.runtime.onSuspend and chrome.runtime.onUpdateRequired but haven't been able to. Thoughts?

[hrg...@gmail.com]

Reloading an extension is the same as disabling it and enabling it again. This should wipe out from memory everything the extension did.

If after reloading the extension you are still seeing an event listener from before reloading, this is most definitely a bug.

The only stuff that should persist after a reload are the various data storages (window.localStorate, chrome.storage.local, IndexedDB, document.cookie).

[wOxxOm]

The crash sounds like https://crbug.com/1239752, fixed in  97.0.4667.0

[Amhed Herrera]

Thanks @w0xx0m

[Amhed Herrera]

We were able to downgrade successfully via transient code that checks for a previous condition that was causing the crash. 

Let's say we have versions 35.1, 35.2, and 35.3, when browsers upgrade, how do they happen? 

a) Like Github, one after the other 35.1 > 35.2 > 35.3, or...

b) In place 35.1 > 35.3

We want to make sure customers upgrade in the correct order otherwise there's an event listener that doesn't get cleaned up and will definitely crash the browser every time/ 

[Amhed Herrera]

We basically need a way to make sure users are on the 35.2 version before upgrading to 35.3. 

Is there any way the chrome team can cherry-pick into that version in case we needed to?

[Simeon Vincent]

Let's say we have versions 35.1, 35.2, and 35.3, when browsers upgrade, how do they happen? 

a) Like Github, one after the other 35.1 > 35.2 > 35.3, or...

b) In place 35.1 > 35.3

Short answer: option B. 

Long answer: it depends. Chrome Web Store is only aware of two versions of your extensions: the published version and the current draft. There's no way for Chrome (or any other client) to request a specific version of an extension because that history is not retained. As such, which versions a given Chrome client receives depends on what versions are available at the times a given client checks for updates. 

To make this a little more concrete, let's take a look at a rough example.

Jan 1: Developer publishes version 1 of their extension.

Jan 2: Chrome client A and Chrome Client B both install version 1 of the extension.

Jan 3: The computer running Client B shuts down. Chrome can non longer check for extension updates.

Jan 4: Developer publishes version 2 of their extension.

Jan 5: Chrome client A downloads and installs version 2 of the extension. This client upgraded from version 1 to 2.

Jan 6: Developer publishes version 3 of their extension.

Jan 7: The computer running Chrome client B starts up and runs Chrome, then downloads and installs version 3. This client upgraded from version 1 to 3.

If you need to apply a linear set of updates (e.g. upgrading the local storage data model), you should implement this in your extension's runtime.onInstalled listener and include all of the historical updates that you reasonably can. Also, if you're using storage.sync, you may want to add runtime guards to ensure that devices using different versions of your extension don't conflict. 

Simeon - @dotproto

Chrome Extensions DevRel

--
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/1e0f6f9e-630c-4ee3-8c6a-903f251d5b76n%40chromium.org.

[ka...@couponfollow.com]

Hey Simeon,

what if we release to only 50% of users?

So in your scenario, we released version 1 to 100% and then version 2 to 50%, and version 3 to 50% of users. What happens when client B wakes up? 

Best,

Kamil