PSA: Extension Update Testing Tool

[Oliver Dunk]

Hey everyone,

I wanted to share that we’ve just published a new tool to GitHub which I’ve been using to test the update flow in extensions (including the permission warnings generated for changes in the manifest): https://github.com/GoogleChromeLabs/extension-update-testing-tool

This is something I’ve often worked around (manually packing extensions and writing XML files for a local update server) and so I’m glad to have a better solution. I’m also really excited to be open sourcing it.

A few of the use-cases:

• Testing what permission warnings are generated for specific changes in the manifest.json file.
• Seeing the update flow, including how an extension is disabled until a user grants additional permissions.
• Testing migration logic between versions (this is possible by simply reloading an extension, but using the update logic is closer to what happens when updating from the Chrome Web Store).

This is still a fairly early release and we have a lot of improvements in mind. We’re also planning some updates to our documentation to explain using this in more detail. But I wanted to share it here first and would love any feedback.

Thanks,
Oliver on behalf of Chrome Extensions DevRel

[Simeon Vincent]

This seems pretty rad. I just ran through a basic test in Chromium and it all seemed to work as I expected. Nice work, Oliver!

Simeon - @dotproto

incremental.software

--
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/a8ef0a38-e807-4ee8-b621-4c87fdf981d4n%40chromium.org.

[Jackie Han]

My experience is as follows:
1. Start the tool (local web server);
2. Install a Chromium build separately (it's a bit of a hassle)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CACA%3D7_a-9WFcnHickRhLik3qu-%3DyquanC1LQYetVcm0jBu7S9A%40mail.gmail.com.

[Oliver Dunk]

Install a Chromium build separately (it's a bit of a hassle)

Definitely appreciate this. I'd love to eventually build more tools into Chrome, but I still think this is still a useful tool for anyone who wants to test the full flow and is comfortable with a bit of additional setup to begin with.

Let me know if you got any further and how the experience was beyond that.

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

[Jackie Han]

Chrome is not allowed to drag and drop a .crx file to install extensions, except on Linux.

So to use this testing tool, developers need to install a Chromium build.

Now, there is a new option: Chrome for Testing.

It is a specific version of Chrome, instead of Chromium. It does not automatically upgrade, and it supports the installation of .crx extensions.

[Oliver Dunk]

Thanks for the callout Jackie! I haven't had a chance to play with Chrome for Testing yet, but if it works that's great.

One note which you may have already spotted, you can use the testing tool with Chrome on Mac and Windows if you follow the steps to install via. policy. It's a little more involved, but I do like that option if I want a test which feels like I'm using a totally real version of Chrome.

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

[Uladzimir Yankovich]

Hey, Oliver 👋 

An excellent and much-needed tool. We have already included it in our testing process.

However, we have a little complication - it signs crx files with a random ID. Is it possible to force him to sign files with the ID we need?

Without this, we cannot fully test the received builds and the update process. Since all requests to our API are protected from requests from extensions with a different ID.

It would be great if we could specify the desired ID in the server settings, as we can now do with the port.

[Oliver Dunk]

Hi Uladzimir,

Glad to hear it! If you have any more details about what you're testing during the release process with this I'd love to know.

On setting an ID, it wouldn't be possible to specify an ID outright, because these are based on the signing key that the tool generates (or in the case of the web store, that the web store knows).

If I added a way to use the same key every time though, would that be enough? It wouldn't be the same ID as your web store listing but would at least be consistent, allowing you to allow-list it on your server.

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

[Uladzimir Yankovich]

Sometimes, during the development process, we update the data storage structure in Storage and write legacy so that new versions put the old data in order at the time of the update.

Therefore, as part of the mandatory regression before release, we install the previous build before each release, fill it with data (create a couple of notes, login, add a couple of tasks, etc.), then update it and check that all the data is in order.

Yes, I think being able always to get a static ID would be a good compromise. We would add it to the list of allowed on our API.

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Oliver Dunk]

Hi Uladzimir,

I've just published a new version of the tool - thanks for bearing with me!

You should now be able to set the `WRITE_KEY=1` environment variable which will read and write a private key from disk to make sure you have a consistent extension ID across runs. Let me know how you get on with that.

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

[Uladzimir Yankovich]

Wow, great! I'll pass this on to our engineer right away!

[Pavel Aronovich]

Hi,

It would be useful to check the operation of the extension locally, which is then set by the policy (CRX) and the PC is included in the domain.

среда, 30 августа 2023 г. в 12:13:55 UTC+3, Uladzimir Yankovich:

[Oliver Dunk]

Thanks for the feedback Pavel!

Are you suggesting we should change something or just pointing out how this could be useful?

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

[Pavel Aronovich]

Yes, this is something that can be useful.

среда, 30 августа 2023 г. в 13:25:05 UTC+3, Oliver Dunk:

[Uladzimir Yankovich]

Colleagues, is there any way to get the pem-key for own extension from the Chrome Store?

I want to test full regression using this stand. However due to a mismatch of keys, authorization does not work.

[Patrick Kettner]

There isn't a way to download an existing PEM file, only the public key. You can add that to your manifest file to force an extension ID, however.

patrick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8a8020d1-513f-4844-af08-f7757140b10en%40chromium.org.

[Uladzimir Yankovich]

I know, but will this trick work with this test server?

It seems to me that he will simply overwrite this key, and that’s it.

[Oliver Dunk]

Unfortunately I don't think it would be possible to use the ID of an extension where the key is currently managed by the Chrome Web Store. It isn't possible to download the PEM file as Patrick mentioned and this is needed to get the same ID.

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

[Jackie Han]

Update: Chrome for Testing 123 doesn't allow dragging a .crx file to install now. My last using Chrome for Testing is 116, that does allow dragging a .crx file to install.

Now, I suggest using a Chromium build for testing. (I am not familiar with installation via policy.)