Google Workspace Default Zoom is Everywhere!

When I started creating my browser extension, I focused on Google Chrome because we use Chrome as our default browser at work. Work is the place I primarily use the Google Workspace suite. Makes sense, huh?!?

But, obviously there are other browsers out there. I want to ensure my extension can be useful to as many people as possible. So, I started trying to figure out how to port my extension to other browsers.

I’m glad to announce, I’ve finally released the extension for both Firefox and Edge! 🎉

New Browsers!!

Firefox

I am only able to offer the base extension for Firefox. This means Firefox users can only use predefined zoom values. I talk more about why this is in the technical details section.

If you use Firefox, you can install the extension via the Firefox 🦊 Add-ons website.

Now those of you who don’t want to ditch uBlock Origin can have this functionality! 😜

Edge

Edge uses Chromium under the hood, so all the features offered in both extension versions worked out of the box!

If you use Edge, you can install the extension from the Microsoft Edge Add-ons website:

1. Google Workspace Default Zoom
2. Google Workspace Default Zoom - Extended
   • In exchange for allowing elevated permissions, this extension provides ability to set custom zoom levels (as opposed to only predefined values)

The Technical Deets (Details)

I know a lot of you come here for the technical details of things, so I won’t disappoint and will get started!

As I’ve pointed out before, I use Plasmo to build my extension. From their website:

Plasmo helps you build, test, and deploy powerful, cutting-edge products on top of the web browser.

And, oh boy, it not disppoint! I was able to get the extension ported to Firefox and Edge relatively quickly.

I think the thing that took me the longest amount of time was figuring out how to become a Microsoft Edge Add-on developer. 😅 It also took me quite a while to configure the Edge store listings, even though I’d already documented them!

And… Edge store reviews take sooooooooooooo long. Dang.

Firefox

Okay, so making the extension available in Firefox was interesting, and I almost gave up a few times. But, I figured it out! Let’s discuss.

Problems with Local Development

Using Plasmo in dev mode was impossible.

Firefox seemed to block the WebSocket connection (I think), which forced the extension to reload itself continuously. This made debugging impossible as the extension was never able to be used (it disappeared and reappeared too quickly). The only way to stop it was to disable the extension via the debugging page and/or stop the Plasmo dev server.

I ended up just running plasmo build after every change and reloading the extension. It was a bit of a pain, but it worked.

First hurdle done!

No Extended Version of the Extension 😞

Since I could now finally “develop” the extension in Firefox, I tried to use custom zoom values. But, it didn’t work.

After some digging, I found an MDN page confirming the debugger permission is unavailable in Firefox.

While it’s available in Manifest V2 and V3, when you actually go the Browser Compatibility section, you can see it’s not supported in Firefox. 😭

This means I unfortunately cannot ship the Extended version of the extension to Firefox. I’m sorry Firefox users! 😞

I’ll keep an eye out for any changes in the future! Promise!

Manifest V2 vs V3

When looking through Manifest differences between Firefox and Chrome, I thought, “Amazing, Firefox is transitioning to Manifest V3. This is the same version used by Chrome. I won’t have to do much to make this work!” I was wrong…

I used Manifest V3 initially. All the docs say to define your Add-on’s ID in the manifest. So, I went looking for my Add-on’s ID. But, don’t you have to publish it first before you get an ID? That’s how the Chrome Webstore works…

After banging my head all over the place, it turns out you don’t have to publish the Add-on to get an Add-on ID. You just create it yourself. Their docs don’t explain this in a straightforward way.

So, I generated a UUID and added it to my manifest in the right form ({UUID}). Cool, Storage API is working. I test all the functionality and it works (minus the extended version part, but whatever). Let’s submit it!

I package the extension locally and start going through the submission process. I get to the point of uploading the ZIP, but the I get a message saying something along the lines of:

We suggest only using Manifest V3 for extensions that are distributed via the “On your own” option. To keep a wide range of support we suggest using Manifest V2 if distributing using the “On this site” option.

Cool, so I move back to Manifest V2 using the format extension-id@example.com. Now, this can be anything as well, just make it up. Their docs do stress it shouldn’t be a real email address as you’ll get spammed, but it can be anything unique.

And after packaging it again, the submission is successful (and later approved)!

I’ve submitted a PR to update Plasmo’s docs relative to Manifest V2/V3 requirements in Firefox. Hopefully this makes it clearer to future users.

Publishing

I’ve automated the publishing process using PlasmoHQ/bpp. It publishes both extensions across the stores for Chrome, Edge, and Firefox.

It was relatively easy to extend for Firefox and Edge, just requiring the additional builds and packaging of the extension for these new targets (and modification of the ENV variables). You can checkout the workflows that handle this for both the default and extended versions if you want to see more detail.

This makes publishing a breeze. All I do is publish a new version using a Git tag and the GitHub Actions takes care of the rest.

Sentry

Now that the extension is working and published across Chrome, Firefox, and Edge, I needed to fix Sentry. Well, doesn’t Sentry just work?? No, it doesn’t just work.

I originally set Sentry up to work with Chrome. Specifically, I only uploaded source maps for the Chrome version of the extension. But, since I now build the extension for each store, this doesn’t work.

Let me break it down a bit more. I’ll use the default version of the extension as an example.

I build the extension three times. Each build targets a different store/browser. This results in three, completely different outputs even though the functionality and source code is the same!

So, since the errors can happen in any of the three outputs, I need to upload the source maps for all of them to the same release in Sentry.

One of my concerns was that the release would be created by during the first upload, then in subsequent uploads it would fail due to trying to create a release that already exists. I had to test it and cross my fingers that it would worked.

Thankfully, it ended up working as Sentry’s GitHub action is smart enough! So now all the source maps for each build are associated to single Sentry release. My GitHub action has more detail if you want it!

Fin

Well, that’s it. I hope this provides some level of value to you (or you find it interesting)!

Until next time...