Re: [crx] Extension updating process (from MV2 to MV3) with .crx files. OnInstalled event does not trigger

[Simeon Vincent]

Specifically I wanted to verify that at the time of the first update to MV3 the extension would copy the contents of localStorage in chrome.storage.local and then get rid of the first one.

To my knowledge there's no copying involved here. Extension storage is segmented based on the extension's ID and web storage is segmented based on origin (again, comes down to extension ID). When you upgrade from MV2 to MV3 the extension will continue to have the same ID, so there's data duplication or migration that needs to be done. The MV2->MV3 process should be transparent for your extension. 

But now I've discovered (with some discomfort) that the chrome.runtime.onInstalled event is not triggered when I drag the .crx of the new version onto chrome://extensions page.

Self signed CRX files dragged onto the chrome://extensions page are disabled on first JS execution on Mac and Windows. This limitation does not apply to Linux. 

Simeon - @dotproto

Chrome Extensions DevRel

On Fri, Apr 9, 2021 at 12:31 PM Roberto Oneto <rob...@gmail.com> wrote:

I'm testing an extension on SRWare Iron browser 89.0.4550.0 (just updated).

I use this browser (in this specific case) because it would seem the only one (or one of the few) that still allows you to install extensions from previously created .crx packages.

I also tried Chrome Canary but they don't like .crx (anymore).

I want to test the extension upgrading dynamics from MV2 to MV3.

Specifically I wanted to verify that at the time of the first update to MV3 the extension would copy the contents of localStorage in chrome.storage.local and then get rid of the first one.

To do this, I create a new tab from the SW where I load an html+js designed for the purpose. (as we know, it is not possible to access localStorage from the SW)

When the job finish then I reload the extension (chrome.runtime.reload) and the tab disappears by itself.

But now I've discovered (with some discomfort) that the chrome.runtime.onInstalled event is not triggered when I drag the .crx of the new version onto chrome://extensions page.

The extension obviously updates, but the script associated with the onInstalled event does not start.

Now my question is:

1) Is this normal behavior given the manual forced procedure?

2) I'm making a big mistake?

3) Should I be worried?

What do you think?

Thanks

--
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/77ade2a3-ff40-4883-8fe0-61b77d398a0fn%40chromium.org.

[Roberto Oneto]

Hi Simeon and thank you for your reply.

I actually deleted the thread after realizing that the old MV2 version of my extension had NOT placed the “onInstalled” event handler in the right place.

I put this event handler inside the DOMContentloaded event handler instead of in the main code flow.

Also, I design my MV2 background script to be not persistent, so it was flushed after 20-30 seconds.

By updating to first MV3 version (which instead has the “onInstalled” event handler placed in the right place) the event WAS NOT triggered either as an "update" or as an "first installation".

This made me think a bit ....

I mean, if I update the extension when the MV2 background is already "gone", I can therefore expect that no listener is listening to nothing (especially when that listener has not been properly installed), but I would expect the newly MV3 listener hears either an "update" or a "first install" event.

At that point, to have some king of verification, I created a third MV3 version (same code with an higher version number) and I dragged\updated again upon the previous MV3 version.

This time the onInstalled event was honored successfully.

A question (perhaps stupid) at this point arises in my head:

"At the time of the update which onInstalled handler is executed?  The one of the old version or the one referring to the new one?"

Help me to do some 'clarity, please.

Anyway now I've fixed it.

When I will be ready to migrate to the store I will need to make sure this important event is honored

so my script will be able to copy the variables previously stored in localStorage in chrome.storage.local

If I didn't do this kind of job then my extension will obviously stop working.

Thanks

[Simeon Vincent]

"At the time of the update which onInstalled handler is executed?  The one of the old version or the one referring to the new one?"

The new one.

It might help to think of the extension as a box with a couple instructions written on different pieces of paper and Chrome as a person opening the box and reading the instructions. When the extension updates, Chrome closes the old box, places it to the side, opens the new box, and starts reading those instructions.

Chrome only knows about one box (one version of your extension) at a time. The onInstalled handler is just an instruction on one of those sheets of paper. It just happens that it is also one of the first instructions that Chrome executes when opening up a new version of your extension.

Simeon - @dotproto

Chrome Extensions DevRel